His Deeds Are Dust

Wow, that was a meaty piece of work. Serafettin Cartoon fonts now builds with the latest release of FontForge, as well as CVS head, and taught me quite a bit about FontForge in the process.

Serafettin had a bunch of glyphs with self-intersection problems, and these were causing FontForge to crash on the Expand Stroke operation. Because Serafettin uses scripts to build the different weights, it was hard to see where the problem was until I made FontForge a lot more verbose about which glyphs it was processing.

Even so, if a glyph self-intersects, it might be impossible to spot how the intersection is happening until you zoom right in and see that what you thought was a sharp corner turns out to be a little twisted triangle of points. If the points are right on top of each other, you won’t see the problem at any zoom level, so you’ll need to trust the Simplify operation.

After all that work, I now have another FontForge bug to report. Try typing a some text ending in ‘+’, like ‘GPLv2+’ into the the TTF name fields. Save your work and observe that the UTF-7 (yes -7, not -8) encoding of the SFD turns this into ‘GPLv2+-’. Now read in the SFD and see that your license field says ‘GPLv2+-’, and subsequent saves will add another ‘-’ every time. Boo, hiss.

I’ve recently been triaging FontForge bugs on Fedora, and hit a problem with bug 600108, in which the latest version of FontForge crashes while building Serafettin.

I patched FontForge locally, so I could identify the glyphs that caused it to crash, but I’ve now come to the conclusion that Serafettin itself is the problem, and FontForge’s validation says as much, in these lines:

• Two glyphs have the same name.
• Two glyphs have the unicode.

I’ve never met these errors before. Sure enough, close examination of Serafettin reveals that there are three copies of some of the glyphs in the font, with the same name and Unicode point. Now that Orcan has given me access to the Subversion repository, I’m currently working on removing the incorrect copies of glyphs, before simplifying the outlines of the rest, to allow it to build again.

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.