this font discussion is interesting and very glad for your insights! but (i feel obliged to point out) it is pretty off-topic, if the topic is the parser code.
but well, forging ahead... i thought i would raise my hand and take sheepish responsiblity for all the nasty rendering code in libavr32 and for the selection of Liquid in the first place (after a significant but not exhaustive consideration of different possibilities), though i did not work on the teletype code in particular.
Odd enough, I get 29 periods until teletype stops printing more on
screen. Which makes me think the limit is not based on how many of the
widest character one can fit on a line.
teletype seems to have a hard limit of 32 characters per line in the scene struct. the rendering library can end up padding the right margin by up to 6px if a glyph would otherwise be truncated. can't spot any other limitation right now, it is a mystery
I am not sure how the empty pixels defined to the sides of each character on the font is truncated by the library.
each entry in the glyph table contains:
- number of blank columns between left edge and start of glyph
- number of blank columns between end of glyph and right edge
- full 6 columns of pixel data, whether they are zeroed or whatever.
the library can render in proportional mode - in which case reads however many columns are appropriate according to the table, then adds one blank column, or in fixed mode - rendering 6 columns for every glyph, plus one blank column. of course the latter doesn't look great, a real monospace font would be better, but at least I's and T's are more or less centered.
in early ui experiments we decided pretty quickly that a proportional font was almost mandatory to fit any significant amount of data on the screen, and so didn't bother going further with monospace. it would be super easy to integrate it though, if you were interested in taking on the design task.
( oh, and i can't think of a technical reason to require an even number of columns for a monospaced font. the rendering regions themselves must have even width, because of the way data is sent to the OLED controller (1byte==2px), but font rendering happens before that, in a flat buffer (1B==1px))
in aleph there is also support for antialiased fonts of arbitrary size, which has been hacked out for libavr32 but can be easily re-added.
and yeah, it's the serif'd 'I' to better distinguish from '1'