His Deeds Are Dust

I still have a VT100 terminal, but it’s in storage. I figured I could pretend that it was on my desk if I made a font that looked like the old beast, including the gaps between scan lines.

Once I’d started, I needed the reverse video form of it, and the forms correctly underlined, and double width, and double height and double width. Blinking is more problematic

The challenge with the double height, double width font is that the VT100 had escape sequences that made particular character rows either display just the top half of characters, or the bottom half. To display characters double height, you had to put the same characters on two consecutive rows, and set the line attributes correctly. In fact, you could make up some funky alien characters by setting the line attributes and typing different characters on each row.

In order to reproduce this effect (yes, I’m carrying on digging), I had to make an upper half font, and a lower half font. And that gives me a problem with Fontconfig, because that takes a look through fonts as it caches them, and marks glyphs as broken if they don’t make any marks, but they are encoded at positions which aren’t space characters in Unicode. My “upper half” font doesn’t have any marks for the underscore glyph, and my “lower half” font doesn’t have any marks for the double quotes, for example.

There isn’t a way of telling Fontconfig that my font isn’t broken just because it didn’t fancy making any marks for a particular glyph, so I’ll have to do some pre-processing when generating “screen shots” of my old terminal. I can locally configure Fontconfig to not do this, but that wouldn’t help anyone else.

A while ago, I recovered my old font files from some crufty old SuperDisks, but did nothing more with them than copy them to my network storage, in the hope that that is a safer home.

Last weekend I was reading about the Fedora Fonts SIG, and decided to bring the old font files back to life. The Fonts SIG is concerned with packaging fonts for Fedora, but their pages have some interesting pointers on how they might be created as well, so I grabbed an old font and explored the tools that are available.

The font I picked is one I created when I was working with an old Stag PROM programmer, back in 1996. The programmer had a 14-segment LED display. The real thing doesn’t look much like the clean vertical pictures you’ll see in that Wikipeda article. The real characters are slightly oblique and there seems to be a kind of hexagonal mesh over the top that makes the segments look like the figure at the top of this posting.

I originally created the font by hand-coding the Type 1 format on a Sun workstation with Ghostscript installed, using my own tools to transform some readable path descriptions into the encrypted form.

This time, it seemed sensible to update the font to OpenType format, and I decided to use FontForge for the job.

Importing the old PFB file worked OK, and exporting is a doddle, except for FontForge complaining about overlapping segments in the font. There aren’t any, but there are some subroutines that move back to the glyph origin, causing some empty subpaths, which FontForge doesn’t ignore.

The only other problem was my attempt to upload the font to the Open Font Library, because the upload facility is broken. Ho hum.

Here’s the result of my hacking, a font called Segment14, released under the SIL Open Font License (OFL): segment14-1.0.tar.gz.

I’ve just been bitten by a bug in pbmclean, one of the tools in the Netpbm package of graphics tools, as provided by Fedora. For a long time, I’ve been building Netpbm from sources, but I’ve been trying to cut down the amount of rework I have to do when updating Fedora, so I’ve moved back to RPMs, but my scanning and cleanup toolchain just broke when pbmclean refused to work at all. A quick test confirmed that it fails for the simplest possible image as well:

$ pbmmake 1 1 | pbmclean > /dev/null
pbmclean: EOF / read error reading a one-byte sample

A bug for this in Red Hat Bugzilla but, if anyone else is experiencing this right now, a simple workaround is pull down the source RPM and rebuild the package without netpbm-10.23-security.patch.

This patch seems to incorporate a load of tests for overflowing arithmetic in image sizes but the “fixes” kill pbmclean and pbmlife, because their tests for row numbers have been incorrectly changed, from:

if (row + 1 < rows)

(in pbmclean.c), to

if (row <= rows)

which clearly isn't the same thing at all. The original tests, although odd-looking, are correct because both pbmclean and pbmlife incorporate row read-ahead, because they change pixels based on the properties of their neighbours.

This bug is present in netpbm-progs-10.35.58-1.fc9.i386.