A Private failing in Segment14

My first upload to the reborn Open Font Library was Segment14, and it failed badly as a web font in Firefox 3.6.17 on Fedora, not displaying at all.

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<unnamed>::ParsePrivateDictData(const uint8_t*, size_t, size_t, size_t, <unnamed>::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.