Font production frustrations and solutions

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?
«1

Comments

  • AbrahamLeeAbrahamLee Posts: 243
    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 BarbaRob Barba Posts: 41
    edited March 16
    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.
  • AbrahamLeeAbrahamLee Posts: 243
    edited March 16
    Rob Barba said:
    For Linux designers, well, I haven't come across any,
    Careful now. We do exist.
  • Cory MaylettCory Maylett Posts: 158
    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?
  • AbrahamLeeAbrahamLee Posts: 243
    Much appreciated, Thomas. So, what production strategies/tools do you recommend to mitigate those things?
  • Rob BarbaRob Barba Posts: 41
    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.   :D
  • Belleve InvisBelleve Invis Posts: 257
    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 PhinneyThomas Phinney Posts: 1,597
    The things in that list that are reasonably subject to automated testing are checked/presented by the AFDKO CompareFamily tool.
  • John HudsonJohn Hudson Posts: 1,659
    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).

  • 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.
  • AbrahamLeeAbrahamLee Posts: 243
    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 PhinneyThomas Phinney Posts: 1,597
    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.  ;)

  • 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 :smile:   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 PhinneyThomas Phinney Posts: 1,597
    edited March 18
    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 louetteivan louette Posts: 262
    edited March 18
    @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 PhinneyThomas Phinney Posts: 1,597
    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 ShinnNick Shinn Posts: 1,435
    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! 
  • AbrahamLeeAbrahamLee Posts: 243
    @Nick Shinn I have actually wondered about that in the past. Good to know to leave that idea alone.
  • Kent LewKent Lew Posts: 892
    @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 ShinnNick Shinn Posts: 1,435
    Yes, it’s Word in Windows 10.
  • 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 EliasonCraig Eliason Posts: 908
    Do your other letters with dotaccents space correctly?
  • Thomas PhinneyThomas Phinney Posts: 1,597
    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 ShinnNick Shinn Posts: 1,435
    I used U+02D9. 
  • Thomas PhinneyThomas Phinney Posts: 1,597
    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.
  • I also used uni0307 with my tests, so it still looks like an issue with the font.
  • Kent LewKent Lew Posts: 892
    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.)
Sign In or Register to comment.