Font production frustrations and solutions

AbrahamLee

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?

John Hudson

Something I learned a long time ago is to make fonts to spec, and not according to what works in a particular application. I know that's a difficult position for a lot of font makers who are licensing fonts to customers who tend to use particular software that does things in idiosyncratic or just plain wrong ways. Customers just want the fonts to work, and are not very interested in how application X is messing up. But if you start making fonts in ways that work in particular apps but which are contrary to the font spec, you risk not only having them not work in other apps, but also in the target apps if the issues get fixed there.

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.

AbrahamLee

Thanks, John. When you say “make fonts to spec”, are you referring to industry font specs (e.g., the OpenType spec) or customer specs/requirements?

Rob Barba

I've found that it's critical to test your fonts in the three main OS environments (Windows, Mac, and Linux).  People get to used to designing it for "their system" and forget about the other two, which leads to problems down the road.

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.

AbrahamLee

Rob Barba said:

For Linux designers, well, I haven't come across any,

Careful now. We do exist.

Cory Maylett

I'm curious about what kinds of "issues" you're running into with them not working as expected in various apps and operating systems. Are you referring to how they look, how they render, how they are listed in menus or, maybe, all of the above and more?

Thomas Phinney

All of the above and more. Including:

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

AbrahamLee

Much appreciated, Thomas. So, what production strategies/tools do you recommend to mitigate those things?

Thomas Phinney

There are  tools I recommend. BUT, they all benefit from the user having a pretty significant knowledge base.    That said, other than OTMaster all my favorites are open source or free.

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. 

Rob Barba

AbrahamLee said:

Rob Barba said:

For Linux designers, well, I haven't come across any,

Careful now. We do exist.

Okay, then I can say I know one now.  

Belleve Invis

Thomas Phinney said:

All of the above and more. Including:

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

FontTools or OTS should include items to test that!

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!

Thomas Phinney

The things in that list that are reasonably subject to automated testing are checked/presented by the AFDKO CompareFamily tool.

John Hudson

Thanks, John. When you say “make fonts to spec”, are you referring to industry font specs (e.g., the OpenType spec) or customer specs/requirements?

Industry font specs. I work through with my clients what their needs are and how to achieve these while retaining spec-compatibility. Of course, this presume that spec exist, which is not the case for OpenType Layout implementation (the font table formats are spec'd, but not how they are to be interpreted and applied by software).

Artur Schmal

Most issues I run into have been mentioned above, and like also mentioned before I use OTMaster a lot for 'post-production' work. It's really a great tool, especially when you're like me not very fluent with command line tools. Also lately I have been consulting the OT spec itself often.

AbrahamLee

Thomas Phinney said:

There are  tools I recommend. BUT, they all benefit from the user having a pretty significant knowledge base.    That said, other than OTMaster all my favorites are open source or free.
...
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.

Maybe this is the real culprit. The more I learn, the more I realize I don't know enough to debug the warnings and errors. I guess experience and time will provide the answers. I will definitely endeavor to become more fluent in those apps/libraries.

Or ask me about about the power-of-two em-square recommendation for TrueType, I dare you. 

Fine, you tempted me ;-) Actually, it's something I've wondered about a lot lately. So, I'm definitely interested in knowing what you have to say about this. I've read and followed the numerous threads here about what units are appropriate for the em-square (even 3333 per em) and I've seen recommendations from Peter Karow that 15,000 per em is the ideal. Not sure if that makes sense nowadays or if apps will curl over and die if a font specifies that, but anyway.

Thomas Phinney

Ah, maximum em size is another issue. IIRC, the problem there is that each format has its maximum coordinate values. I believe it is +/- 4096 for CFF. (Perhaps CFF2 has increased that?) I don’t recall the TrueType maximum off the top of my head.

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. 

Santhosh Thottingal

Thomas Phinney said:

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/

Another Linux based designer here   It would be really great if the Linux version of this tool made to work with latest versions of popular distributions. For example, it does not work in Ubuntu 18.04 or 18.10. There are some hacks to get it working, I was told, but that destabilize your working operating system. There is also a problem of no functional light version to try out before purchasing. I confirmed the above details by contacting DTL.

Thomas Phinney

Linux is such a minuscule market for OTMaster that I, for one, am shocked that DTL continues to make the Linux version of the app available at all. I imagine it is because some of their folks use Linux internally.

ivan louette

@Thomas Phinney I am a Linux designer too.

I think Open Source and Linux are popular amongst developpers in Netherlands : for example think at the Blender 3D project, which is a great success. That's perhaps why DTL propose these versions. And that's why I would be interested to use DTL OTMaster in the future.

Thomas Phinney

I think open source and Linux are popular amongst developers elsewhere as well. But—perhaps not entirely surprisingly—that doesn’t necessarily translate to a bunch of people licensing software for money, to run it on Linux.

Nick Shinn

Here’s another buggy thing: 
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! 

AbrahamLee

@Nick Shinn I have actually wondered about that in the past. Good to know to leave that idea alone.

Kent Lew

@Nick Shinn What’s the buggy behavior that you’re experiencing, and with what version[s] of Word?

I know DJR has built his /i’s from composites in at least a few fonts, and I’ve never heard him report feedback about Word bugginess. I don’t know if he’s taken to doing this regularly now, but I think so. On the other hand, his customers are not likely to be using Word. ;-)

Nick Shinn

Yes, it’s Word in Windows 10.

Erwin Denissen

It seems to work just fine here. I tested both a font with TT and CFF based outlines. I'm more than happy to test your font here as well. I'm also running Windows 10.

Craig Eliason

Do your other letters with dotaccents space correctly?

Thomas Phinney

Huh. In Nick’s case, it seems as if perhaps... Word could be adding the sidebearings of the components together? Which I would not expect, but I can understand that Word might expect the combining accent to have zero advance width. 

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.

Nick Shinn

I used U+02D9. 

Thomas Phinney

I suggest you try either setting its advance width to zero, or better still use U+0307 (which should definitely have an advance width of zero).

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.

Erwin Denissen

I also used uni0307 with my tests, so it still looks like an issue with the font.

Kent Lew

Given that the dot accent outline is being referenced as a component, I don’t understand how its advance width would come into play during rendering. But it does seem that this could be the source of the bug. FWIW, I’ve only seen examples with the zero-width dotaccentcmb U+0307 used for this type of construction. (And I’ve never tested it in Word on Windows.)