fixed-width HTML5 <canvas> font rendering in a page of JS
Kragen Javier Sitaker
kragen at canonical.org
Sat Jan 28 22:17:53 EST 2012
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
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
More information about the Kragen-discuss