As someone still becoming familiarized with everything that goes into the production stages of fonts, I'm realizing more and more that there's a lot that goes into turning a *typeface design* into a rock-solid *font* than I would've guessed when I started out. And yet, with everything I've learned, I still occasionally run into issues where my fonts don't always work as expected on different operating systems and apps. One of my deepest frustrations is the rapid pace that font support/expectations are evolving and, thus, what used to be correct is no longer the best thing to do.
So, I'm curious if anyone would be willing to share a thought or two about issues you've run into trying to make reliable fonts that work as cross-platform/app as needed and what you did about it. What tools do you find most useful and do you find that you become aware enough of what the tools help you with that you no longer need them?
2
Comments
In terms of tools, I use DTL OTMaster a lot. I know the ideal is to have a single tool source that spits out a fully functional, perfect font, but I can't recall ever being able to do that: all my projects involve multiple tools. That's partly due to the complexity of the fonts I'm making, and partly to the source requirements of some of my clients, but in general there comes a point where I need to edit some piece of data directly within the TTF/OTF font file, and then OTMaster is invaluable. [Using TTX to edit table data is also possible, but I like OTMaster's interface and checker tools.
For Mac users, it's easy: just run Windows emulation (via Wine) and "Linux on a stick" (Sugar Linux is good for that, and Ubuntu is as well) to test.
Windows folks have it a bit harder, but there are still options. I have a friend who uses Mac and he's my guinea pig. Something similar may be available for you, if you look (I know; easier said than done). Likewise, for her needs, my wife maintains a Mint Linux box and we test my fonts on that for those purposes.
For Linux designers, well, I haven't come across any, but I would presume the answer is similar to a mix of the above.
- Fonts getting smeared bold in some Windows apps (but not all)
- because Windows GDI doesn’t really expect OS/2.weightclass values to be anything other than 400 or 700, and bad things happen with values under 250, and also with some combinations when bold style linking is involved.
- Family divisions being different between platforms/apps
- Individual style names differing in unexpected ways between platforms/apps
- Weird ways in which some piece of metadata causes an unexpected problem.
- Example: Setting the Panose digit that indicates a font is monospaced will cause at least some Windows APIs (GDI at least) to ignore actual advance widths in the font and treat it as monospaced, based on some specific advance width.
- Some styles just not showing up at all in some platforms or apps
- Special shout-out to InDesign treating Book and Regular as synonyms, so only one shows up, unless the app specifically has your family’s existence in a hard-coded list. That is super confusing unless you happen to magically know about it.
- Windows-specific rendering problems (because Windows uses the hints built into the font, while at most normal sizes, macOS autohints on the fly and ignores the built-in hints)
- Some Linux environments use the hints built into the font, and some don’t, and this may be user-controllable. So, extra fun.
That’s just off the top of my head! there are many more, those are just the ones that spring to mind.Of course your font editor that you are working in is the number one tool. But after that....
DTL OTMaster: great tool, a zillion uses. Just nice for being able to look inside the font and get a relatively clean look at the innards without as much interpretation. They have added more “checking” functions as well, it just keeps getting better. The only third-party app we re-sell at FontLab: https://www.fontlab.com/font-utility/dtl-otmaster/
ttx/FontTools: Whether or not you use anything else in FontTools, the ttx ability to just dump a font to an XML representation is awesome. Plus, it can recompile that representation back to a font—even if you have edited it in between. Certainly one of the inspirations for the live code view in FontLab VI. https://github.com/fonttools/fonttools
Adobe CompareFamily: this tool is part of the AFDKO tool set, which requires you have Python and ttx/FontTools installed. Command-line driven and outputs text to screen or a file, written in Python. It evolved to include many single-font checks as well as family-wide checks—just dozens of checks and tests, including looking out for many idiosyncratic issues noted in my previous post. CompareFamily got its origin some time around ~2000 or so (as best as I recall). I was frustrated that there were so many ways of checking things in individual fonts, but nothing that looked at relationships between style-linked fonts or compared family members for consistency. As best as I recall, I had the idea and started specifying it, and Ernie March and others helped out as well (and of course continued developing it long after I left in 2008). Read Roberts wrote the actual tool. https://github.com/adobe-type-tools/afdko
Microsoft Font Validator: It literally looks at every table in the font and tries to validate all the data for compliance with the OpenType spec and recommendations. It is a crazy complicated task. Not saying it checks literally everything, but it certainly looks at a lot of things! Windows-only, and creates an XML file, which you then need to view with something (could be a web browser).
Fair warning: the Adobe and Microsoft tools both have predictable (and not unreasonable) biases towards meeting their creators’ needs and preferences. You have to tell each one which tests you want it to do, and in some cases set some prefs or variables. Microsoft’s tool does not look inside a CFF or CFF2 table, last time I checked, even though it validates (TrueType) outlines and the like—so, a TTF bias. Adobe’s tool does not do much with outlines and absolutely nothing TrueType-specific—so, an OTF bias. Plus assorted minor preferences and assumptions by each tool.
Elaborating on that “needing a significant knowledge base,” what I mean is, when a warning or error is reported, is it one you should care about? How much so? Under what circumstances? Heck, there are at least a few warnings and errors that are in CompareFamily, because I specified them, that I myself am uncertain exactly how important they are today! I suspect that the average type designer is less likely to know that sort of thing.
Or ask me about about the power-of-two em-square recommendation for TrueType, I dare you.
I know that the @-font generation (for vertical layout) requires the VERT feature and its lookup being written in a specific manner. You won't know that before you start a kernel debugging.
Why? Of course, for reducing one memory allocation!
As for the power-of-two recommendation, that refers to the idea that a TrueType font will have better rasterizing performance if its em square is a power of two, which is why 2048 is the default em square for TrueType. Some key folks at Microsoft have said that this remains true today. Some key folks at Adobe have said this was only true due to a peculiarity of the instruction set of the Motorola 68000 series CPUs, and is therefore irrelevant today.
I think that either way, it is a great example of how stories behind spec recommendations can get lost in the mists of time and cause confusion downstream.
I thought I would be really clever and make the /i character as a composite from dotless i and dot accent. But of course, Word doesn’t like that!
Nick, when you make the composite glyph from components, do you use a NON-SPACING dot to add to the dotless i? That is, U+0307, should have an advance width of zero. (Not U+02D9, which should have a significant positive advance width.)
If not, you might try that and see if it resolves the problem.
I can imagine that while this feels like a Word bug, Microsoft folks will say you should only use the zero-width combining character for this purpose.