I have annother one, in order to better understand this I converted only a single char of full NotoSans-Regular.ttf.
And then I went a step further and disected the .xfont files.
ASTC 8x8: 2 bits per pixel
mapped: !singlechar1.txt, Size: 32, ASTC auto, Compression Speed: thorough
" ꙱ " - U+A671 - 0xea 0x99 0xb1
Format : COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed : thorough
Layout Width : 64
Layout Height : 5
Pixel Width : 32
Pixel Height : 40
Number of characters in xfont file : 42624
Number of characters in user input file: 1
Success: 1
Fail : 0
NotoSans-Regular_32_ASTC_1.png 32 x 40 - 1 glyph
NotoSans-Regular_32_ASTC_1.glyph 86720 bytes
32*40*2 = 2560 bits -> 320 bytes
86720 / 320 = 271
NotoSans-Regular_32_ASTC_1.xfont:
0 0x0100aaff Signature
4 0x00000b1f Total size of the font block, in bytes: 2847
8 0x000093b7 Bitmap format: COMPRESSED_RGBA_ASTC_8x8_KHR
12 0x0000024a Bitmap swizzle value: 10 0100 1010
16 0x00000040 Font bitmap line stride, in bytes: 64
20 0x00000005 Font bitmap height, in pixels: 5
24 0x00000020 Font screen width, in pixels: 32
28 0x00000028 Font screen height, in pixels: 40
32 0x00800080 Pointer to font graphic data in memory, including flash: address in flash, 4096 (128 * 32)
36 0x0000a680 Total number of characters in font(N), multiple of 128: 42624
40 0x0000b2c0 Offsets to glyph data - N/128 -> 42624 / 128 = 333
...
1348 0x0000b2c0 Offset to glyph data
1352 0x00000000 Offset to glyph data
1356 0x00000000 Offset to glyph data
1360 0x00000000 Offset to glyph data
1364 0x00000000 Offset to glyph data
1368 0x000012c0 Offset to glyph data
1372 0x00000a90 Offsets to width data - - N/128 -> 42624 / 128 = 333
...
2696 0x00000a90 Offset to width data
2700 0x00000a9f Offset to width data
2704 0x00000000 Width data, one byte per character
...
2828 0x00000000 Width data, one byte per character
2832 0x0000001E Width data, one byte per character
2836 0x00000000 Width data, one byte per character
2840 0x00000000 Width data, one byte per character
2844 0x000000 Width data, one byte per character
mapped: !singlechar2.txt, Size: 32, ASTC auto, Compression Speed: thorough
"Ω" - U+03A9 - 0xce 0xa9
Format : COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed : thorough
Layout Width : 64
Layout Height : 3
Pixel Width : 32
Pixel Height : 24
Number of characters in xfont file : 1024
Number of characters in user input file: 1
Success: 1
Fail : 0
NotoSans-Regular_32_ASTC_2.png 32 x 24 - 1 glyph
NotoSans-Regular_32_ASTC_2.glyph 32640 bytes
32*24*2 = 1536 bits -> 192 bytes
32640 / 192 = 170
NotoSans-Regular_32_ASTC_2.xfont:
0 0x0100aaff Signature
4 0x00000b1f Total size of the font block, in bytes: 2847
8 0x000093b7 Bitmap format: COMPRESSED_RGBA_ASTC_8x8_KHR
12 0x0000024a Bitmap swizzle value: 10 0100 1010
16 0x00000040 Font bitmap line stride, in bytes: 64
20 0x00000003 Font bitmap height, in pixels: 3
24 0x00000020 Font screen width, in pixels: 32
28 0x00000018 Font screen height, in pixels: 20
32 0x00800080 Pointer to font graphic data in memory, including flash: address in flash, 4096 (128 * 32)
36 0x00000400 Total number of characters in font(N), multiple of 128: 1024
40 0x00001f70 Offsets to glyph data - N/128 -> 1024 / 128 = 8
...
64 0x00001f70 Offset to glyph data
68 0x00000000 Offset to glyph data
72 0x0000092 Offsets to width data - - N/128 -> 1024 / 128 = 8
...
96 0x0000092 Offset to width data
100 0x0000068 Offset to width data
104 0x00000000 Width data, one byte per character
...
140 0x00000000 Width data, one byte per character
144 0x00001900 Width data, one byte per character
148 0x00000000 Width data, one byte per character
...
268 0x00000000 Width data, one byte per character
272 0x0000 Width data, one byte per character
And to check if the fonts are working I generated a flash image and fed it to ESE:
CLEAR(1, 1, 1)
CMD_SETFONT2(10, 0, 0)
CMD_SETFONT2(11,4096, 0)
CMD_TEXT(95, 213, 10, 0, "꙱")
CMD_TEXT(140, 222, 11, 0, "Ω")
0 0x26000007 CLEAR(1, 1, 1)
1 0x0500000a BITMAP_HANDLE(10)
2 0x28000000 BITMAP_LAYOUT_H(0, 0)
3 0x07f88005 BITMAP_LAYOUT(GLFORMAT, 64, 5)
4 0x2e0093b7 BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_8x8_KHR)
5 0x2f00024a BITMAP_SWIZZLE(ONE, ONE, ONE, RED)
6 0x29000000 BITMAP_SIZE_H(0, 0)
7 0x08004028 BITMAP_SIZE(NEAREST, BORDER, BORDER, 32, 40)
8 0x0500000b BITMAP_HANDLE(11)
9 0x28000000 BITMAP_LAYOUT_H(0, 0)
10 0x07f88003 BITMAP_LAYOUT(GLFORMAT, 64, 3)
11 0x2e0093b7 BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_8x8_KHR)
12 0x2f00024a BITMAP_SWIZZLE(ONE, ONE, ONE, RED)
13 0x29000000 BITMAP_SIZE_H(0, 0)
14 0x08004018 BITMAP_SIZE(NEAREST, BORDER, BORDER, 32, 24)
15 0x22000000 SAVE_CONTEXT()
16 0x27000002 VERTEX_FORMAT(2)
17 0x06000000 CELL(0)
18 0x0500000a BITMAP_HANDLE(10)
19 0x1f000001 BEGIN(BITMAPS)
20 0x01800580 BITMAP_SOURCE(0x800000 | 1408)
21 0x40be0354 VERTEX2F(380, 852)
22 0x23000000 RESTORE_CONTEXT()
23 0x22000000 SAVE_CONTEXT()
24 0x27000002 VERTEX_FORMAT(2)
25 0x06000000 CELL(0)
26 0x0500000b BITMAP_HANDLE(11)
27 0x1f000001 BEGIN(BITMAPS)
28 0x01800c66 BITMAP_SOURCE(0x800000 | 3174)
29 0x41180378 VERTEX2F(560, 888)
30 0x23000000 RESTORE_CONTEXT()
Okay, there is a correlation between the number of chars in the .xfont file and the Unicode number of the char.
U+A671 -> 42609 -> 42609 / 128 = 332,8 -> 333 blocks of 128 needed
U+03A9 -> 937 -> 937 / 128 = 7,3 -> 8 blocks of 128 needed
So the higher the number the last char in the set is, the longer the .xfont file gets.
But how do we get to the glyph?
a671
1010 0110 0111 0001
101001100 1110001 -> block number 332, glyph number 113th ?
glyph offsets:
0-327: 0x0000b2c0
328-331: 0x00000000
332: 0x000012c0
And now I am lost.
This directly addresses the glyph:
17 0x06000000 CELL(0)
20 0x01800580 BITMAP_SOURCE(0x800000 | 1408)
The "1408" is in units of 32 bytes.
This works fine as well:
CMD_SETBITMAP(0x800000 | 1408, COMPRESSED_RGBA_ASTC_8x8_KHR, 32, 40)
VERTEX2F(1600, 100)
But how does the glyph-offset in the .xfont file lead to this address?
Regarding the sizes, it looks like there are actually three images in this .glyph file?
And the one that contains the actual glyph needs to be larger than the glyph itself since
its absolute address is calculated somehow from the lower 7 bits of its Unicode number?
That explains the size of the .glyph file, unclear math or not, the .xfont only has information about blocks
of 128 glyphs and calculates the absolute address of a glyph from the offset-address of the block, the lower 7 bits of the Unicode number and probably the character widths.
This means the .glyph file itself has to be bigger than the glyph to allow for that structure.
So adding more glyphs to a group that already is present does not make the .glyph bigger?
mapped: !CharMap2.txt, Size: 32, ASTC auto, Compression Speed: thorough
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ £°±²³µ¼½¾ÄÖ×Üßäöü"
Format : COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed : thorough
Layout Width : 96
Layout Height : 6
Pixel Width : 48
Pixel Height : 48
Number of characters in xfont file : 256
Number of characters in user input file: 113
Success: 113
Fail : 0
NotoSans-Regular_32_ASTC.png 48 x 5424 - 113 glyphs
NotoSans-Regular_32_ASTC.glyph 145472 bytes
48*48*2 = 4608 bits -> 576 bytes
145472 / 576 = 252,5
That theory seems to be holding some water as the size of the .glyph is exactly the same as with the !Charmap.txt file from my earlier post that has ten glyphs less.
So the glyphs for the not existing codepoints are of the same width and height but empty?
The .xfont file also has the same size, the extra ten glyphs probably had no impact on the width data.
That leaves the potential issue that empty pages seem to take up quite some space in the .glyph file as well.
Oh yes, and that "Full Unicode Characters" does not convert the glyphs that are contained in the font but
generates a file with 65535 glyphs is odd as well.
In any case, working with a charmap-file works a lot better than stripping unicode-ranges from a given font and doing a full-convert on that stripped font.
And it is a lot faster.

- March 08, 2021, 04:17:33 PM
- Welcome, Guest
News:
Welcome to the Bridgetek Community!
Please read our Welcome Note
Technical Support enquires
please contact the team @ Bridgetek Support
Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology
1
on: March 07, 2021, 01:19:13 PM
|
||
Started by Rudolph - Last post by Rudolph | ||
2
on: March 05, 2021, 02:33:05 PM
|
||
Started by Rudolph - Last post by BRT Community | ||
Hello Rudolph,
Thank you for your detailed analysis of this issue, I have passed this onto the development team for investigation. Best Regards, BRT Community. |
3
on: March 04, 2021, 02:11:11 PM
|
||
Started by DAVOSS - Last post by DAVOSS | ||
Thank you it helped !
|
4
on: March 03, 2021, 11:02:52 PM
|
||
Started by Rudolph - Last post by Rudolph | ||
Hello,
I’ve had some clarification from the developers regarding Unicode font conversions: This does not appear to be working and it might never did work so far. In "full" unicode range the output always is 65536, regardless how many glyphs the font actually contains and regardless of that the number of glyhs is successfully identified. In the attached fonttest.zip you find font_metrics.txt with details about the different conversions in the set. I used the included notosans-regular-webfont2.ttf for this test which is a reduced subset of NotoSans-Regular.ttf from Google. I converted it down to 135 glyphs and the highest glyph is 0x25fc / 9724. Quote Then, number of characters is determined by: (max code point + 128 ) & ~ 127. For example if one input character set includes a character whos max code point is 382 (ž), then the .xfont will list 384 characters: This is not what I got, I have a set which includes only a single char beyond 0x00fc and that is 0x02da. And the number of characters in the xfont file is reported as 256 for a total number of 103 chars in the set. I would guess that there is at least one block of 128 for each code-block. The full set of 135 glyphs for this font should report 5 * 128 = 640 as the chars are from five different blocks. Quote The metric table (.xfont) will include the number relating to the max code point, and will include padding to the relevant code points for a characters width data. The sizes in this test set are all over the place. In full the converter just appears to be broken. It appears that it generates glyphs for 655536 codepoints although there are only 135 glyphs in this example. And this happens with all fonts that I feed it this way. I set the compression to ASTC and auto which got me 8x8 for all conversion and which is 2 bits per pixel. full 135 glyphs: notosans-regular-webfont2_32_ASTC.glyph 377280 bytes, 48x48 pixel -> room for 655 glyphs 103 glyphs: notosans-regular-webfont2_32_ASTC.glyph 145472 bytes, 48x48 pixel -> room for 252,5 glyphs 95 glyphs: notosans-regular-webfont2_32_ASTC.glyph 73728 bytes, 48x48 pixel -> room for 128 glyphs 14 glyphs: notosans-regular-webfont2_32_ASTC.glyph 24576 bytes, 32x25 pixel -> room for 128 glyphs 10 glyphs: notosans-regular-webfont2_32_ASTC.glyph 24576 bytes, 32x25 pixel -> room for 128 glyphs The sizes of the glyphs with ASTC 8x8 and their pixels perfectly align to 32 bytes. As last exercise I just converted the notosans-regular-webfont2_32_ASTC.png that was generated when conveting to 95 chars with ANSI_32_126.txt. As ASTC 8x8 the file only has 54720 bytes and not 73728 bytes as the .glyph. The notosans-regular-webfont2_32_ASTC.png has 48x4560 pixels. I cut out a single glyph of 48x48 pixel. Converted to ASTC 8x8 the .raw file has 576 bytes. Looking at the compressed data, the .glyph file looks suspicious, not exactly like the ASTC 8x8 raw and the .glyph has a higher compression ratio when zipped as the .raw file has. |
5
on: March 02, 2021, 11:37:08 PM
|
||
Started by Matrix Orbital - Last post by Matrix Orbital | ||
We have released new sample code, this time for the Arduino UNO.
It is VERY basic code, mainly to get you started This code will illustrate:
please note, this example does not utilize touch Detailed information: http://www.brtcommunity.com/index.php?topic=229.0 |
6
on: March 02, 2021, 11:12:46 PM
|
||
Started by Matrix Orbital - Last post by Matrix Orbital | ||
Basic EVE Arduino UNO Example Code
Written for an EVE2 or EVE3 or EVE4 running on an Arduino UNO. Code is located on GitHub https://github.com/MatrixOrbital/Basic-EVE-Demo-Arduino This code when executed will display MATRIX ORBITAL text and a blue circle. This code will illustrate:
please note, this example does not utilize touch ------------------------------------------------------------------------------------------ Hardware Requirements Designed for Matrix Orbital EVE2/3/4 SPI TFT Displays https://www.matrixorbital.com/ftdi-eve Scoodo EVE TFT SHIELD for Arduino https://www.matrixorbital.com/eve2-shield LIBRARY This code makes use of the Matrix Orbital EVE2 Library found here: https://github.com/MatrixOrbital/EVE2-Library While a copy of the library files (Eve2_81x.c and Eve2_81x.h) is included here, it will not be updated. For the most up to date files please use the files from the link above. EVE SPI TFT connected to a Scoodo SHIELD Support Forums http://www.lcdforums.com/forums/viewforum.php?f=45 |
7
on: March 02, 2021, 04:05:13 PM
|
||
Started by Rudolph - Last post by BRT Community | ||
Hello,
I’ve had some clarification from the developers regarding Unicode font conversions:
Then, number of characters is determined by: (max code point + 128 ) & ~ 127. For example if one input character set includes a character whos max code point is 382 (ž), then the .xfont will list 384 characters: (382 + 128) & ~127 = 384 If another input character set in used which include for example the trademark symbol (™), its max code point would be 8482, and the .xfont would list 8576 characters: (8482 + 128) & ~127 = 8576 The metric table (.xfont) will include the number relating to the max code point, and will include padding to the relevant code points for a characters width data. However only the characters included in the input character set will be converted to the .glyph data. I will need to investigate why you are seeing such large .glyph files when converting these fonts with differing character sets. Could you provide the input char set and font file you are using during conversion? Best Regards, BRT Community |
8
on: February 27, 2021, 12:42:12 PM
|
||
Started by Rudolph - Last post by Rudolph | ||
I was playing with EAB v2.1.0 RC2 conveting fonts and found
that the "Font Size" can not exceed 255. That is a little inconveniant as I was trying to convert a numbers-only subset to as large as possible. I used a numbers.txt file containing only " +-.0123456789" and with a "Font Size" of "only" 255, the result in pixels for Funtype.ttf and these 14 chars is a width of 180 and a height of 192. Also, that "Full Unicode Characters" is still not working exactly like it should. For Funtype.ttf ( https://fontlibrary.org/de/font/funtype ) the preview states: This font contains 364 glyphs. And this is accurate. The font conversion log however has this: Format : COMPRESSED_RGBA_ASTC_8x5_KHR Compressed : thorough Layout Width : 64 Layout Height : 4 Pixel Width : 32 Pixel Height : 20 Number of characters in xfont file : 65536 Number of characters in user input file: 65536 Success: 65536 Fail : 0 And when I use a charmap.txt file to limit the characters converted I get this: Format : COMPRESSED_RGBA_ASTC_8x5_KHR Compressed : thorough Layout Width : 32 Layout Height : 4 Pixel Width : 16 Pixel Height : 20 Number of characters in xfont file : 8448 Number of characters in user input file: 106 Success: 106 Fail : 0 The numbers reported do not match. Also the Funtype_12_ASTC.glyph with 106 chars is 48384 bytes long. But the Funtype_12_ASTC.glyph which should have 364 glyphs since the font does not contain more, it has a size of 307.072 bytes. That is almost twice the size that I would expect when going from 106 chars to 364 chars. And talking about sizes, again, there appears to be a severe issue when converting fonts. 16x20x106 is 33920 So an uncompressed array of 16x20 pixel images in L8 format of 106 individual images would be smaller than what the font converter currently presents as COMPRESSED_RGBA_ASTC_8x5_KHR. 8x5 is 3.2 bits per pixel and when I compress a single image of 16x20 from this font, the result is 320 bytes in L8, and only 128 bytes as COMPRESSED_RGBA_ASTC_8x5_KHR -> works. So the data for the glyhs should be around 13568 bytes but the resulting .glyph file is over 3.5 times that size. There also is the option to generate the font in L8 format. The resulting Funtype_12_L8.glyph for 106 glyphs of 16x20 pixels has a size of 106560 bytes. Why? That is 3.1 times the expected size. I thought this might be an issue with alignment of images in FLASH but then the requirement is 32 bytes aligned. 128 bytes for COMPRESSED_RGBA_ASTC_8x5_KHR already is perfectly aligned. Even adding 32 bytes to every glyph does not account for the size. And when using RAM_G as a target for the ASTC compressed font the .glyph file has the exact same size. So no, alignement can not be the issue. Also L8 does not even allow the data to be in FLASH. |
9
on: February 26, 2021, 05:04:32 PM
|
||
Started by DAVOSS - Last post by BRT Community | ||
Hi,
It may depend on which version of the library you use but the GD2 library has a function to call the calibrate command, void GDClass::self_calibrate(void) { cmd_dlstart(); Clear(); cmd_text(w / 2, h / 2, 30, OPT_CENTER, "please tap on the dot"); cmd_calibrate(); finish(); cmd_loadidentity(); cmd_dlstart(); GDTR.flush(); } Best Regards, BRT Community |
10
on: February 25, 2021, 07:01:16 PM
|
||
Started by Cyrilou - Last post by Matrix Orbital | ||
Cyrilou,
I couldn't see what display you are using, but if you are using a Matrix Orbital EVE display you can use this module here to upload directly into the NOR Flash https://www.matrixorbital.com/eve2-usb2spi-kit-a ![]() |