The font support added yesterday works with compact byte tables stored in flash ROM to store all the “glyphs”, i.e. pre-computed bitmaps.

Here’s the entire table of the clR6x8 font:

All the characters are stored side-by-side in a very wide horizontal bitmap image. In this case, the height is 8 pixels and the width = 72 x 8 = 572 pixels.

In detail:

• H: the height of the image, in pixels (1 byte)
• W: the width of the image, in bytes (1 byte)
• the image data, 8 horizontal bits per byte (H x W bytes)
• F: the code of the first character stored for this font (1 byte)
• N: the number of consecutive characters in this font (1 byte)

And then it depends on whether the font is monospaced or proportional. For a mono-spaced font, i.e. where all the glyphs have the same size:

• P: the number of horizontal pixels per glyph (1 byte)
• A: the “pre-gap” (value -4..11, encoded as 4 bits by adding 4 to it)
• B: the “post-gap” (value -4..11, encoded as 4 bits by adding 4 to it)

The pre-gap defines where to start copying the glyph, relative to the current horizontal position. A negative value causes kerning. Likewise, the post-gap indicates where to start writing the next character. IOW, after a character has been processed, the horizontal position is advanced by P + B pixels (A does not participate in this calculation).