So I've been playing with various fonts on a ks0108 GLCD.
I've seen that font header files created by Fabien Maximilian Thiele's fontcreator are pretty popular/common but the data format chosen for font heights that are not multiples of 8 seems to be odd and suboptimal.
I'm wondering if there was some specific reasoning for using this format that I'm not seeing/understanding.
The ks0108 chip wants to write data in 8 bit pages with the bits starting at the top and
increasing vertically down.
i.e. bit 0 is above bit 1 and bit 7 is the bottom of the 8 bit page/column.
fontcreator creates a nice avr gcc style header file that can be used and does order the bits in the correct order for easy access when using vertical 8 bit pages - most of the time.
The issue I'm seeing is that when the font is not a multiple of 8 bits in height, the fractional left over bits are in the least significant bits rather than most significant bits.
While doing it this way can be made to work,
it greatly complicates and slows down the code.
For example, suppose you have a 6x10 font.
(6 wide by 10 tall)
Something like a
2 rows of six bytes, where the top
row of six bytes would contain the upper 8 horizontal lines of pixels and the bottom row of six bytes would contain the 2 bottom horizontal lines of pixels with 5 unused bits of padding.
The top row of six bytes is all 0xff as expected, but lower row of six bytes is 0xc0 rather than 0x03
It is like font bits are pushed into the font data bytes from MSB to LSB rather than building the byte by dropping in the bits starting in bit 0 up to bit 7.
When you have fractional bytes being used,
essentially what happens is that all the unused bits are left down at the LSB end of the byte. i.e the pad/unused bits are down low instead of up high in the byte.
This really complicates writing the character font data to the LCD as it is not in "normal" bitmap format and you have to run-time calculate the amount of right shift needed on the font data.
If it were in normal bitmap format, you could simply use normal bitmap drawing routines to draw characters just like any other bitmap.
This can be worked around by having special character font drawing routines that account for this run-time detect how much to shift the data to the right as needed. All the sample libraries that I've seen (including Thiele's) have special code to deal with the bottom/last byte for partial bytes.
However, all of these special font drawing routines I've seen, have errors in them and don't work properly when the fonts are not multiples of 8 bits in height. They don't properly treat the character as a bitmap and end up improperly rounding vertical/Y addresses to page boundaries and stomp on pixel data beyond the lower edge of the font.
Yes, this too can also be fixed with additional code.
But if the font data bytes were created with the pad bits in the upper bits rather than the lower bits, things could be simpler, and the special font drawing and all the PITA code and exceptions for the padding bits could go away.
To me it seems odd to burden run-time code with additional calculations that could be eliminated by changing the format of the static data.
Maybe its the way I'm looking at things related to how the ks0108 works, but it would seem better if the pad bits were moved to the upper bits rather than the lower bits.
Has anyone else seen this, or am I the only "crazy" one?