Please Help Understanding U8G2 Font Data Structure

[gentlesartori]

Hello! I am working on learning how U8G2 works and I would really appreciate a little guidance.

The background is that I am developing (another) LCD emulator, similar to what @roberto314 did back in 2019, but I am working in a graphical programming language called LabVIEW. Because of this, I have to manually port the code. I have made a lot of progress; so far I am able to convert the octal/ASCII strings in u8g2_fonts.c to a byte array, parse the font header information, and I can parse the first 4 bytes of the glyph header (encode, width, height). The last two I achieved using a combination of bit masking and logical shifting.

Now I am at the point where I am trying to parse out the signed values. Referencing your diagram from your February, 2019 post:

xhhhhwww pyyyyyxx 1000pppp ------f1
01001111 01000010 11101100 01101010 10011111 01100011 00000000

Before I get into RLE decoding, I want to understand the data structure better. Will you please clarify;
Why are values labeled x and p not contiguous? Are the bytes meant to be handled as words, with different endianness (byte swapped)?
What is the meaning of the bits that are labeled with '1000' above them, before pppp?

Once I get this nailed, I want to get into RLE. I am confused by how the repeat flag works, and how to handle it with multiple repeats. But that can wait :-)

This has been a really fascinating project for me. I really appreciate all the work that went into writing U8G2! Thank you!

Best wishes,

gentle

[roberto314]

I am sorry. This was such a long time ago i don't have any clue how i did that. If i remember correctly the RLE Part was also hard for me and i did ask oli.

…

--robert

On Thu, Feb 6, 2025 at 5:58 PM gentlesartori ***@***.***> wrote: Hello! I am working on learning how U8G2 works and I would really appreciate a little guidance. The background is that I am developing (another) LCD emulator, similar to what @roberto314 <https://github.com/roberto314> did back in 2019, but I am working in a graphical programming language called LabVIEW. Because of this, I have to manually port the code. I have made a lot of progress; so far I am able to convert the octal/ASCII strings in u8g2_fonts.c to a byte array, parse the font header information, and I can parse the first 4 bytes of the glyph header (encode, width, height). The last two I achieved using a combination of bit masking and logical shifting. Now I am at the point where I am trying to parse out the signed values. Referencing your diagram from your February, 2019 post: xhhhhwww pyyyyyxx 1000pppp ------f1 01001111 01000010 11101100 01101010 10011111 01100011 00000000 Before I get into RLE decoding, I want to understand the data structure better. Will you please clarify; Why are values labeled x and p not contiguous? Are the bytes meant to be handled as words, with different endianness (byte swapped)? What is the meaning of the bits that are labeled with '1000' above them, before pppp? Once I get this nailed, I want to get into RLE. I am confused by how the repeat flag works, and how to handle it with multiple repeats. But that can wait :-) This has been a really fascinating project for me. I really appreciate all the work that went into writing U8G2! Thank you! Best wishes, gentle — Reply to this email directly, view it on GitHub <#2586>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH6PK7VZM5HKSQU7TH2PP432OOIE5AVCNFSM6AAAAABWUA3KYGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHEZDINRRGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- mit freundlichen Grüßen. Ing. Robert Offner MSc.

[roberto314]

Mayb this will help:
FontDisplay.zip

[gentlesartori]

I'll take a look. Thanks. Hoping Oli will provide more background as well.

[olikraus]

Hi All, let me first link the original post: #824

xhhhhwww pyyyyyxx 1000pppp ------f1
01001111 01000010 11101100 01101010 10011111 01100011 00000000

Why are values labeled x and p not contiguous?

They are continues, but the decoding will start at bit position 0. However for a byte, the representation usually has bit 0 at the right position.
So in order to understand the bit stream, we probably should swap the bit positions:

76543210 76543210 76543210
xhhhhwww pyyyyyxx 1000pppp

01234567 01234567 01234567
wwwhhhhx xxyyyyyp pppp0001

The upper line gives the bit position. If we rewrite the bit position, then the bitstream is visually a proper continues stream. However for the below explaination I keep the "none-continues" visual representation.

Are the bytes meant to be handled as words, with different endianness (byte swapped)?

No, this as nothing todo with endianness, see above.

What is the meaning of the bits that are labeled with '1000' above them, before pppp?

This is already the start of the bitmap data. Maybe the use of 1 and 0 is confusing.
Let's better use z (number of zero bit count value) and o (number of one bit count value):

original:

xhhhhwww pyyyyyxx 1000pppp 11000ff1 -------f
01001111 01000010 11101100 01101010 10011111 01100011 00000000

updated with o and z:

xhhhhwww pyyyyyxx ozzzpppp oozzzffo -------f
01001111 01000010 11101100 01101010 10011111 01100011 00000000

Let me rewrite the values from the bitstream in a table:

Bit Start	Byte Start	Bit End	Byte End	Bit Size	Bit Mark	Value	Bit Value	Dez Value
0	0	2	0	3	www	Glyph Width	111	7
3	0	6	0	4	hhhh	Glyph Height	1001	9
7	0	1	1	3	xxx	Glyph X Offset	100	4 - (1<<(3-1))=0
2	1	6	1	5	yyyyy	Glyph X Offset	10000	16-(1<<(5-1))=0
7	1	3	2	5	ppppp	Glyph X Delta	11000	24-(1<<(5-1))=8
3	2	6	2	3	zzz	Clr Pixel Cnt	110	6
7	2	0	3	2	oo	Set Pixel Cnt	10	2
1	3	1	3	1	f	Repeat	1	1 (yes)
2	3	2	3	1	f	Repeat	0	0 (no)

Hope this is more clear...

[gentlesartori]

Yes, I think that answers my question very well. Thank you! I will take some time to fully digest this and implement it in my project.