Make your font work in Windows

When you produce fonts, there are typically three environments you care about: web browsers, Adobe apps, and Windows. Or particularly, Word on Windows. If you make it there, you can make it anywhere.

Speaking of Word: when it comes to fonts, there is quite a difference between Word on the Mac and Word on Windows. While this article is about Windows, it also contains notes about what is different in Word on the Mac.

TrueType

If you are producing fonts for Windows, the obvious choice is to export them as TTFs (with a .ttf file name suffix), and avoid CFFs (with an .otf suffix). Why? For two reasons. Firstly, some functions, most notably document embedding, require TrueType fonts. You cannot embed CFFs. And if you export a PDF with a PS-based OTF, its outlines will be bitmapped first. Here is the top-left part of an O in a PDF exported from Word on Windows:

Yeah. I wish I was making this up.

Secondly, TTFs perform better than CFFs, to the point where you type a word, then cross your arms and lean back in your chair while watching the letters appear on the screen one by one. To be fair, this happened with a font that contained rather complex outlines, but still, the TTF version of it worked fine. So, yes, only TTF for Windows.

TTFs need a digital signature, a.k.a. DSIG table, otherwise Word on Windows will not recognize it as an OpenType font, and no OpenType features will work, including ligatures and kerning. By default, Glyphs automatically adds an empty DSIG to your TrueType exports. However, you can force or suppress it with the custom parameter Export DSIG Table. Word of mouth has reached me that such a digital signature may not be necessary in recent versions of Word on recent versions of Windows. It does not hurt to include it anyway, not just for backwards compatibility, but because many font testing environments (e.g. on font sales platforms) will complain otherwise.

Test installs

Your best guess is a virtualization solution like Parallels from the AppStore. Get one of the subscriptions that comes with Windows right away. And while you’re out shopping, get an Office 365 subscription from Microsoft. Up to five users can install Office with it, and as a nice collateral benefit, you get to install the Mac version as well, with the same license.

Installing fonts is one of the things Microsoft did better than Apple. All you need to do is right-click the font files and pick the hilariously obvious More Options:

After which, a second context menu will appear, from which you can choose Install:

This is not better than Apple, you will say. And you are right when it comes to the boring fact that you have to wade through two context menus for the one thing one can possibly want to do with font files. However, when you need to reinstall them, you just do it again, and the old font installations are overwritten, and activated right away. Wow. No font cache issues. Good job, Microsoft.

Once you have them installed, just pick them in Word from the Font window, which you can access through Ctrl-D or Ctrl-Shift-F:

Actually, a mini version of the font picker will appear as soon as you select any text:

Removing fonts from the system is easy. You navigate to This PC > Local Disk > Windows > Fonts. This is where all installed fonts live, grouped by family. You right-click and choose Delete from the context menu, and gone they are:

If you want to delete individual fonts from a family, double click the family first.

Glyph set

Make sure you always have the Win 1252 character set covered. Plus, all type-able characters you expect on the intended enduser keyboards. Otherwise, you risk fallback font substitution. That means that people type something, hit an unintended key for a character that is not represented in your font, and most Office software (including Word for Windows) will typically substitute with the first available font that supports that character. And, any character typed thereafter. Yes, it literally changes your font.

For the Win 1252 charset, see Languages > Latin > Legacy Encodings. While you’re at it, also cover the Mac Roman you find there to avoid similar issues in Word for the Mac:

Make particularly sure you have all quotes and dashes covered: you will find them in Categories > Punctuation > Quotes and Dashes in the Font View sidebar. This is important because Word auto-substitutes quotes and dashes while the user is typing. And that again can cause font fallbacks.

If you have lining tabular figures in your font, make them your default figures. Windows users will complain otherwise. You heard it here first. You can do that on the fly with Rename Glyphs and Update Features parameters in Font Info > Exports:

The Rename Glyphs parameter would contain code like this, assuming you stick to the standard glyph naming, and you have proportional default figures (without a suffix) and tabular figures with a .tf suffix:

zero=zero.lf
one=one.lf
two=two.lf
three=three.lf
four=four.lf
five=five.lf
six=six.lf
seven=seven.lf
eight=eight.lf
nine=nine.lf
zero.tf=zero
one.tf=one
two.tf=two
three.tf=three
four.tf=four
five.tf=five
six.tf=six
seven.tf=seven
eight.tf=eight
nine.tf=nine

The above code will move the existing proportional figures into a set of .lf suffixed figures. Then it moves the .tf figures into the default names. The Update Features parameter will recalculate your lnum (Lining Numerals) and tnum (Tabular Numerals) features, and you’re all set.

Family

Everything that is to be said about forming families between multiple fonts can be found in the Naming tutorial. In a nutshell, Word only knows 4-member ‘RIBBI’ families. RIBBI is short for Regular, Italic, Bold, Bold Italic. The idea is that you select a family in the font menu and choose the other family members through the B and I buttons.

That means on the other hand that any style that cannot be reached through a B and I button, counts as a separate family. In effect, non-RIBBI weights will be listed as separate entries, sorted alphabetically, i.e., Black comes before Semibold, etc. Their respective italics though are reached with the I button again.

If you do not like this, well, tough luck. This is the logic of font menus in Windows (or at least Word for Windows), so deal with it: accept that you cannot change Word into InDesign with some magical hack in your font. Even Microsoft cannot reorder their own fonts:

This is different on the Mac version of Microsoft Office, by the way. There you get all styles sorted by families, and within the family by width and weight class:

Speaking of weight classes, you may have heard that the lowest weight class you should use is 250, because Word artificially boldens fonts set to weight classes below that value, because it deems them to thin to display otherwise. I have good news for you: you do not need that anymore. The weight class bug has been fixed for more than 20 years. So you can use the full range of weight classes, all the way from 1 through 1000. But what about backwards compatibility? Please, no. Anyone who is such a cheapskate that he or she runs a version of Word a quarter century old, is unlikely to shell out a dime for your font. In other words, you can safely ignore that segment of the market.

Two pieces of advice about naming. Firstly, keep your names short, both family and style names. That is a good idea because Windows font menus are very small, and sometimes, if it is too long, older versions of Windows will complain that the font is ‘invalid’. However, since version 11, Windows seems to handle long names just fine.

Secondly, it appears that some letter combos are not allowed in names. We can confirm that this is at least true for NOR (all caps), which caused the font to not show up in the Word font menus. One might assume that this may be related to words being reserved for coding, in this case the boolean ‘nor’ operator. But then again, AND works fine in the name. In any event, if your font does not appear despite trying everything, try changing its name and see if that helps. If you think you discovered another forbidden letter combo, let us know in the forum, and I’ll update this tutorial.

Vertical metrics

OK, so the idea of vertical metrics is to somehow find a good sync (or compromise) between three sets of metrics:

• OS/2 winAscent and winDescent
• OS/2 typoAscender, typoDescender and typoLineGap
• hhea ascender, descender and lineGap

And always have OS/2 selection bit 7 activated, a.k.a. ‘Use Typo Metrics’. But that is the default in Glyphs 3 and later anyway.

What these metrics should do: the OS/2 Win values should be used for clipping exclusively. For determining the line positions, Windows should use OS/2 Typo, the Mac should use the hhea metrics. The bad news is, that if you have Use Typo Metrics on, Word on Windows will use the OS/2 Typo values for both clipping and line positioning. That is a bug, and it is unlikely to be fixed anytime soon.

And by the way, Word for Mac always uses the hhea values for both line positions and clipping, no matter which bit is set. So, whichever vertical-metric strategy you are following, always sync the Typo and hhea values with each other, and make sure they do not cut into any of your important glyphs.

This is a pain for multi-script typefaces that need to combine very different vertical metrics, e.g., Latin and Arabic. In such a case, you (or your client) just need to decide then what is more important: tight line-fitting or no glyphs cut off on-screen. You cannot have both in Word, sorry.

Hinting

If you plan to use ttfautohint, make sure you turn on Windows Compatibility because it introduces alignment zones on the OS/2 winAscent and winDescent positions, reducing the chance of accidental clipping. For everything else about hinting with ttfautohint, yes, do read the tutorial.

OpenType features

I have to admit, getting features to work is the most opaque thing ever. Even if you do everything that is asked of you here, the features may still not work in Word on Windows. Why? We do not know. What we do know, however, is that you have to double check that your font has a DSIG table (see above), and your Languagesystems are properly set in Font Info > Features, otherwise Word will go on strike. The good news: Glyphs does that automatically, though you may have to push the Update button every once in a while.

The way to check if it works in Word on Windows, is to press Ctrl-D to open the font menu, choose your font if you have not already, and then proceed to the Advanced tab. There you will either cry in despair because all the options for features are greyed out:

Or you can open your Champagne bottle because they are actually available:

This window is also what you need to educate your clients about. Now you belong to the 0.1% of the world population that knows about the Advanced tab in the Word font window, but chances are your client has no clue about it. OT features that should be on by default in any app, they need to be enabled by the user in Word, and it has to happen right there.

Yes. You can only activate one stylistic set at a time, and their names are not displayed in the menu. So either don’t overdo its with stylistic sets, or give options where you merge some of the sets in another set. But then again, most Windows users have never heard about stylistic sets, so don’t worry about it too much.

No OpenType feature whatsoever will ever work in PowerPoint. PowerPoint has a codebase so old, inflexible and broken, don’t even think of making anything work in PowerPoint.

Color

Word on Windows, along with other apps, supports CPAL/COLR. So, if you want colors, just follow the tutorial and you’re good. But… there’s one more thing, I’m afraid. You cannot mix colorfont technologies, it has to be pure CPAL/COLR. Especially, do not add SVG. Because if you do, Word will ignore all color info and only reproduce the (black-and-white) fallback layer.

Sigh. So much for a cross-platform compatible color font. Our recommendation: in your TTF exports, enable COLR table export, and disable SVG table export. Can easily be done with custom parameters in File > Font Info > Exports:

Kerning

Getting kerning to show in Microsoft apps is a science in itself, but here are some things that have worked before. However, there will be situations where, even if you did everything right, it will still not work. Here we go.

For kerning to work, …

• … pair adjustment kerning needs to be merged into a single lookup, with a custom parameter called Keep Kerning in one Lookup, added to Font Info > Exports:

  

• … there should be at least one other GPOS feature in the font. Mark-to-base mark or mark-to-mark positioning mkmk will do. Keep this in mind when you try to optimize your font with the Remove Features parameter. Don’t remove those two.
• … it needs to be enabled in the Advanced tab of the Font window (Ctrl-D, see above): Set the minimum size for kerning to something ridiculously low, like 1 point. Don’t ask me why Microsoft makes their users go through this.

In some cases, users reported that kerning will only work between encoded glyphs. However, I cannot confirm that. Sure, you can try adding PUA codes to unencoded glyphs and see if that helps. My guess is it won’t. That is, unless you resort to flatten the kerning. What is that, you ask? Well, read on.

Last resort for kerning

OK, no matter what you do, kerning is simply not working? Here are three things you can try as a last resort.

Switch to variable fonts

An unlikely solution for many issues in Windows, including making kerning work in PowerPoint, is to export your typeface as variable font. In File > Font Info > Exports, create a new variable font setting, and add a family name that is different from the default family name in the Font tab. That’s necessary for avoiding a font naming conflict, typically you will use the family name with an added ‘Var’ or ‘Variable’. Then export through File > Export > Variable.

With a little luck, this is it. In my tests, this even makes kerning work in the notoriously incompatible PowerPoint.

The dist hack

There are actually a few OT features even Word cannot ignore, because they are essential for some scripts to work in Office. One of those features is the Distances feature, or, in short: dist. It is necessary for South Asian and Brahmic scripts to function, and therefore always on.

We can piggyback ride on the dist feature by calling the kerning lookup in the Distances feature. Assuming you added the Keep Kerning in one Lookup custom parameter already, all you need to do is add another custom parameter called Add Feature, pick the dist feature, and add this line:

lookup kern_DFLT;

This will be the name of the first lookup in the kern feature. And since dist is added after the kern feature, we can call that lookup from there. If you did everything right, it will look like this:

If you do not contract them in one lookup with the Keep Kerning in one Lookup parameter, it will look more like this:

lookup kern_DFLT;
lookup kern_latn;
lookup kern_cyrl;

…et cetera, you get the idea. For every script that has kerning, add a lookup call for kern_XXXX where XXXX is the OpenType script tag. Avoid scripts that do not have kerning or that are not even in your font.

However, keep in mind that this is a hack. And it may cause the font to malfunction in other apps, so it is a desperate hack. While it may work in the current version of Word, and your client is happy, it may not work in others. What’s worse, it may break your Opentype features altogether. So I do not recommend it. My experience is also that it doesn’t work in recent versions of Office. But hey, your mileage may vary, and maybe you’re lucky.

Flatten kerning

In an OpenType font, kerning information is stored in the kern feature, which in turn is part of the GPOS (‘glyph positioning’) table. The great thing about this kind of kerning is the ability to do something called group kerning. Essentially, group kerning means that if you kern AY, then ÄY, ÃY, ÁY, as well as AÝ, and even impossible combos such as ÅŸ are kerned in the same way. That is because all these letters are part of groups, in this case the A group containing all A diacritics and the Y group containing all Y diacritics.

In the dark ages before OpenType, there was no such thing as the GPOS table with a kern feature. And thus, there was no group kerning. You could only kern a bunch of individual glyphs with each other in the kern table. Yes, table, not feature. To avoid confusion between kern table and kern feature, the table is sometimes referred to as ‘old-style kern table’, or ‘pre-OpenType kern table’. Anyway, the limitations of the kern table were not a big problem because fonts would only contain 200 glyphs or so, and only a bit more than half of them were letters. You would typically end up with anything between 1000 and 2000 glyph pairings that made sense. But nowadays, even basic fonts count 500 glyphs and more, yielding tens of thousands of potential pairings, cracking the delicate limits of our good old pre-OpenType kern table any day of the week.

What if we smashed the GPOS table into pieces and had an old-style kern table instead? After all, this is what always used to work (even in PowerPoint, cough, cough) back then, when our granddaddies built the first computers with stones and wood sticks.

Yes, that actually works, but it means breaking your font again: no more group kerning, plus you will have to do subsetting for the most important glyph-to-glyph pairs, losing a lot of the kerning information on the way. This is what the Kerning > Kern Flattener script in the mekkablue scripts does. It first duplicates your font (i.e., it works on a copy), adds kerning for a predefined number of glyph pairings, and removes all group kerning and any GPOS features you may have had. So, Window > Kerning will look like this, with no groups:

Finally, it adds a well-hidden, top secret custom parameter to your exporting instances. It is called Export kern Table:

This suppresses the kern feature in the GPOS table and instead adds an old-style kern table to your TTF export. (The parameter does not work in CFF OpenType fonts, because before OpenType, tables only existed in TTFs, so there was never a kern table in a PostScript-based pre-OpenType font. Pre-OpenType PostScript fonts were structured very differently.)

Export from the file duplicate, and then close it without saving, because all it contains is a broken version of your font. Then, install your fresh exports and keep your fingers crossed while you install them in Windows and try them in Office.

Good luck.

Links and more info

• The topic is frequently discussed in the forum.
• ATypI Tech Talks 2022, ‘Make Your Fonts Work in…‘, section Word and Microsoft Office.
• Typedrawers: Making OT/TTF layout features work in MS Word 2010 (including the rationale about the DSIG table).

Update 2024-06-12: added clarification about Unicode and kerning, and a note about NOR letter combo, thx Göran!
Update 2024-07-04: corrected two typos.
Update 2024-07-23: added Color section.
Update 2024-10-02: added variable font solution for kerning.