I’m sure he won’t mind if I tell you that the email was from someone who has worked on a ton of retro tech fonts himself.

The email started with a compliment, which is always nice, and then continued by saying that he’d downloaded the FX-80 manual and found that the bottom row of my lowercase “g” was out by half a pixel.

I nearly fell off my chair laughing, because that’s exactly what I would do!

Christopher Adams confirmed that it worked on the WebKit-based browsers Safari and Midori, and it works on my HTC Desire.

After some minor, unrelated, cleanups, FontForge gave both the SFD and OTF files a clean bill of health, but it still wasn’t working in Firefox, so I took a deeper look and found that Mozilla had added the OTS font sanitizing library to Firefox from version 3.6.13, back in December 2010.

OTS is mainly designed to be added as a font condom for OpenType-consuming applications, as Firefox apply it, but it also has a standalone checker called ot-serialize. OTS isn’t packaged in Fedora yet, so I collected it from upstream and ran it over my font, with these results:

ERROR at /home/paul/projects/ots/ots-read-only/src/cff.cc:377 (bool::ParsePrivateDictData(const uint8_t*, size_t, size_t, size_t, ::DICT_DATA_TYPE, ots::OpenTypeCFF*))

Ugly. Still, it’s a “yes/no” tool, so I’m prepared to do a little hunting through the source to find out exactly why it hates me.

The answer is that my FontForge source had a definition of BlueValues in the Type 1 Private dictionary. I don’t remember how it got there, because it is optional, but I had put one in, and I had defined it as an empty array. OTS decided that, if arrays exist in the Private dictionary, they must not be empty. With a quick snip, my font works again.

I’ll certainly be adding OTS to my fonty toolchain, and it strikes me that this would be a useful tool for packaging and using in font reviews. You wouldn’t want to fail a review because of it, but it would certainly help to know whether a font will fail on the Web, which must be a large part of users’ expectations now.

I’m using Firefox 3.6.17 on Fedora 14, and it stubbornly refuses to show up as a web font. As far as I can see, every other one of the 36 fonts on the site displays correctly, but Segment14 shows up as the fallback serif.

Christopher Adams took a look for me and says that it works just fine on Safari and Midori, which suggests that the fault lies with Firefox, but I’m left wondering which bug I’ve tripped over.

This is bug 789283 on OFLB’s Launchpad, in case anyone has any clues.

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 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.