On Sat, Jan 28, 2012 at 11:24:52PM +0100, Dave Long wrote: > the Hershey fonts render pretty nicely in <canvas> ...
I'm sure — but they're not hinted, so I don't expect that they'd be at all readable in 5×6 pixels. And Janne V. Kujala's 4×6 font is one step further removed. On the plus side, one thing I've been thinking about is holographic archival, one frame per viewing angle, for which Hershey-like sparsity could be a great advantage! Kujala's font has about a 30% "duty cycle", but the lower the "duty cycle", the higher the contrast ratio, in a hologram. Stroke fonts can give you an arbitrarily low duty cycle by getting bigger. I designed the 5×6 font included in the data: URL to include no "saddle points" within a character, that is, points where two white and two black pixels diagonally touch one of the same type. I thought this attribute might be handy for, say, cutting stickers of the glyphs out of colored plastic sticky tape. Kujala's font offers the intriguing possibility of making readable (vertical) text with only four LEDs or other similar all-or-nothing actuators: spray cans, pens, smoke emitters. (And he almost always uses only three.) Either mine or his will work for making readable horizontal text with six of them. It's an interesting question whether you can do with less than six vertically if your "pixels" are very tall and skinny. Hershey's outline fonts are useful for a different family of minimal robotics and art, such as, famously, engraving. It would be interesting to see a ASCII vector font of a minimal amount of data. The printable ASCII part of Kujala's font contains 4*6*96 = 2304 bits, 288 bytes, 3 bytes per glyph, and I think you could probably fit a program to render text in it (say, in mode 13) into another 32 bytes of 8088 assembly. Could you do a reasonable vector stroke font in a similar amount of space? You could, for example, drop 16 pegs into a character cell, and then use two or three bytes per glyph to define which pegs are the endpoints of the three to five strokes for the glyph. Would that be enough to get readable text? What if the 16 pegs are evenly spaced around a circle instead of being a 4×4 grid? Or you could read a 16-bit glyph encoding as 8 2-bit movement commands: north, south, east, west. Seven bits per glyph is almost enough with seven-segment displays, but you only get a single case, and "m" and "w" suffer badly. Would 12 bits be enough to get readable text by a similar approach? Hofstadter's "gridfonts" are probably too big: 21 points in a 3×7 grid, with an unlimited number of line segments connecting adjacent points, possibly even diagonally-adjacent points. There are 12 squares containing 6 segments each, of which the inner 16 are shared between two squares and thus double-counted, for a total of 56 possible segments: nearly 8 bits needed to encode a single segment! Kragen -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss
