Understanding the font format and differences between font arrays and bitmap arrays

[Gaai]

When writing a string, u8g2 looks up the individual char data in the font array and somehow converts the data in there to a bitmap right? I am trying to understand how so I can use the same data to draw the pixels as a preview on a webpage. I gleamed some insight from reading https://github.com/olikraus/u8g2/wiki/u8g2fontformat. Like the data in the font arrays is compressed in a few ways to save memory. But I still feel pretty ignorant. Please correct me if I am wrong:

• The data is packed right? Because the width/height of each character is known and declared in a seperate header?
• Also instead of declaring individual (consequtive) pixels on or off, 'lines' of ones or zeros sequences are stored as a startpoint and a length?
• More...

FONT ARRAY of exclamation mark:

/*
  Fontname: single_char
  Copyright: Created with Fony 1.4.7
  Glyphs: 1/1
  BBX Build Mode: 0
*/
const uint8_t exclamation_mark[36] U8G2_FONT_SECTION("exclamation_mark") = 
  "\1\0\2\2\1\4\1\1\3\1\10\0\0\0\0\0\0\0\0\0\0\0\7!\5qs\5\0\0\0\4"
  "\377\377\0";

Would be nice if someone perhaps could explain from the above font array (from a single exclamation mark char "!"), how I should mentally parse this data. And also what objections there are against using bitmap arrays for custom font characters.

BITMAP ARRAY of exclamation mark:

const unsigned char image_exclamation_mark_black_bits[] U8X8_PROGMEM = {0x01,0x01,0x01,0x01,0x01,0x01,0x00,0x01};
u8g2.drawXBMP(0, 0, 2, 8, image_exclamation_mark_black_bits);

Apart from the fact that u8g2 provides a string print function that does the character lookup and placement/spacing for me and the memory storage benefits due to the compression smartness. Does the string drawing have other benefits over using bitmap arrays for my custom font characters and using my own print function?

[olikraus]

The data is packed right?

Depends on what you mean by "packed". But yes, some values are bit encoded in the byte stream. I mean, if certain values do not require a full byte, then only some bits are used.

Does the string drawing have other benefits

lookup of glyphs is faster and also the drawing itself is faster, because the low level drawing function in u8g2 allows drawing repeated pixel of the same color. So the RLE compression also optimizes data transfer via the low level procedures.
In fact it may make sense to convert bitmaps into glyphs and store the bitmaps as fonts (https://github.com/olikraus/u8g2/tree/master/tools/font/png2bdf)

Would be nice if someone perhaps could explain from the above font array

puh, this is just a spare time project... If you have a specific question I can try to answer this.

[Gaai]

That's a speedy response. I really appreciate this, knowing you've got other things to do too. Thanks for all the great work that went into all this.
Interesting that it's faster. I'll try to have a look at the source.
Yes, a breakdown of the array format for a single char, like the explanation mark one I posted is perhaps a bit too much to ask for. I get that this takes time to explain. If there is someone out here who could spare the time, it would surely be appreciated. Perhaps I can figure it out on my own too. I'll try and else look for a different method. 🙂✌️

[olikraus]

At least the first 22 bytes are described here:

u8g2/csrc/u8g2_font.c

Lines 45 to 74 in 8430f65

	offset bytes description
	0 1 glyph_cnt number of glyphs
	1 1 bbx_mode 0: proportional, 1: common height, 2: monospace, 3: multiple of 8
	2 1 bits_per_0 glyph rle parameter
	3 1 bits_per_1 glyph rle parameter
	4 1 bits_per_char_width glyph rle parameter
	5 1 bits_per_char_height glyph rle parameter
	6 1 bits_per_char_x glyph rle parameter
	7 1 bits_per_char_y glyph rle parameter
	8 1 bits_per_delta_x glyph rle parameter
	9 1 max_char_width
	10 1 max_char_height
	11 1 x offset
	12 1 y offset (descent)
	13 1 ascent (capital A)
	14 1 descent (lower g)
	15 1 ascent '('
	16 1 descent ')'
	17 1 start pos 'A' high byte
	18 1 start pos 'A' low byte
	19 1 start pos 'a' high byte
	20 1 start pos 'a' low byte
	21 1 start pos unicode high byte
	22 1 start pos unicode low byte

The actual glyph will start at the "!" symbol (no surprise the encoding for "!" is "!")

That "!" is also the glyph start itself, which is described in the second table in the description: https://github.com/olikraus/u8g2/wiki/u8g2fontformat

Actually there are two versions of the glyph table, one with only one byte as encoding and one with two bytes for the encoding.
Here there is only one byte, so "!" is the code itselt.
After this there is the delta to the next glyph "\5", so the size of the "!" glyph is 5+1
"qs\5\0\0" then finally is the bit encoded information, which contains

First the glyph properties are read, which starts here:

u8g2/csrc/u8g2_font.c

Lines 590 to 591 in 8430f65

	decode->glyph_width = u8g2_font_decode_get_unsigned_bits(decode, u8g2->font_info.bits_per_char_width);
	decode->glyph_height = u8g2_font_decode_get_unsigned_bits(decode,u8g2->font_info.bits_per_char_height);

and continues here:

u8g2/csrc/u8g2_font.c

Lines 623 to 625 in 8430f65

	x = u8g2_font_decode_get_signed_bits(decode, u8g2->font_info.bits_per_char_x);
	y = u8g2_font_decode_get_signed_bits(decode, u8g2->font_info.bits_per_char_y);
	d = u8g2_font_decode_get_signed_bits(decode, u8g2->font_info.bits_per_delta_x);

after this the bitmap RLE starts.

[Gaai]

Awesome thanks! Will dive in there.