For a long time I thought of the PANOSE numbers in fonts as only used for things like font matching, without any practical impact in most day-to-day use of fonts. I am reminded this week of how dangerously wrong that belief is.
For those who are unfamiliar with it, the PANOSE number of a font is a chunk of metadata that describes the font with a sequence of digits, an encapsulated description. Here’s the PANOSE section in FontLab Studio’s Font Info pane.
This week, for the second time in the past 15 years, I discovered a WIndows font bug caused by improper PANOSE numbers in fonts, which I had never heard of before.
The first bug was simple: if you set the appropriate PANOSE digit to say the font is monospaced, Windows will ignore the actual advance widths in the font and treat every glyph as having the same advance width. This means that you had better not set the PANOSE to monospaced unless the font is utterly and completely monospaced. This may seem simple, but consider that some supposedly-monospaced fonts still have ligatures. If, say, the fi ligature is to have a different width than the i by itself, then the font is not truly monospaced and setting the PANOSE to monospaced will mess up that glyph’s advance width (at least, in many Windows applications, though not most Adobe apps).
If my understanding is correct, the new bug is also simple: if you have a style-linked family such as a regular and an italic, the general PANOSE class had better be the same for every family member, or else Windows will get very confused. In my case, the regular was of the “Latin Decorative” class and the very early build of the italic was “Latin Text” (because I hadn’t bothered developing the PANOSE number yet for the italic). Some very odd symptoms occurred for a user with an existing document in Word 2010 on Windows 7.
This is also a lesson in font testing. Even something as simple as coordinating family members for Windows, a mostly well-understood area, and one in which I have considerable expertise, can fail for unknown reasons. There is no substitute for actual testing in apps: this issue was not identified by Adobe’s fabulous CompareFamily test tool, probably because they had never encountered it. I had used the italic by itself in Word on Windows, and both the fonts together in Creative Suite apps, and all was well. That was simply insufficient.
Definitely a major error on my part. Certainly, this was not a final release, but even a pre-alpha build released to my Kickstarter backers, as the new italic was, should behave more reliably than this one did.
