8 February 2025
It’s time to rename this series of posts, as I haven’t been using any sort of RISC-V assembly language at all in this project lately.
So now on to bigger and bolder fonts.
9 February 2025
So not a lot of work got done on the project yesterday, but I did have some time to think about it. And it occurred to me that bit-mapped fonts are great when they’re small but start to take up a lot of resources, i.e., memory space when they get bigger.
My mental arithmetic last night suggests that the biggest possible font on a 128 x 64 pixel display would be 64 x 64 pixels per character, giving a total of two characters on a single line of text. They would be perhaps a bit too squarish for my taste, so I could slim them down a bit and have 42 x 64 pixel characters, allowing up to 3 characters, but still only a single line of them. As I have defined 96 glyphs in my first font design for this project, I project that it would take 32K of memory space for just this one font. The target chip at the moment has 62K of memory available, so perhaps we’ve come up both a good minimum and maximum size for this display. As a point of comparison, the existing font that I have lovingly named font_5x8 takes up 480 bytes of memory.
Pondering further, a font sized to allow two lines of text would be 32 bits tall, 3 lines would allow up to 21 bits tall and four lines would divide nicely into characters 16 bits tall. It was at this point that it occurred to me that bit-mapped fonts were not the only way to go, especially on a resource-constrained device such as I’d prefer to use.
Another option are stroke or vector fonts. Instead of a predetermined array of ones and zeros are used to map out the appearance of the individual characters, a series of lines and perhaps arcs are described for each glyph.
A famous set of vector fonts was developed around 1967 by Dr. Allen Vincent Hershey. Like myself, he struggled with the age-old question of “but which font should I use?” as well as how to do so in an efficient way. These fonts are now referred to collectively as “Hershey fonts”. They use a relatively compact notation to describe a set of strokes between integer coordinates on a Cartesean plane, resulting in very legible characters.
Now while I smile quietly to myself for my efforts to give the world lower case characters with descenders, Dr. Hershey spent untold hours designing and transcribing characters in as many languages as he could find.
I found a copy of the original data file as part of an archive on:
https://media.unpythonic.net/emergent-files/software/hershey/tex-hershey.zipWithin this archive, a file called, simply, ‘occident’ contains a number of lines (1,610, to be exact), each defining the appearance of a single character. They are numbered from 1 to 3,926, as not all the characters are present in this file.
Now I would like to write a simple-ish program to plot these characters to the OLED module and see what they look like. This ‘program’ will be more of a system that has a portion that runs on my laptop and another that is running on the embedded device.
I’ll start writing the big-end of the system in Python and the little-end in C. The big-end will read in the data file in its entirety and convert the provded encoding into a series of ‘move to’ and ‘draw to’ commands for the OLED. So it turns out I’ll be needing those line generating functions, after all.