by Thomas Phinney
Periodically somebody asks how InDesign prioritizes fonts whose names conflict, or what consistutes a conflict, and nobody knows. Recently David Blatner (InDesignSecrets.com, co-author of Real World InDesign, Real World QuarkXPress, etc.) asked the same question, and sparked me to pull together the answers.
There are three kinds of name conflicts in InDesign that cause fonts to potentially not show up in the font menu.
1) Duplicate PostScript FontName
2) Duplicate menu name (as shown in InDesign)
3) Multiple “regular”-like styles in a single family
The third case is a bit different, so we’ll take it separately.
GENERAL NAME CONFLICTS
(This first section owes a great debt to Michelle Hill, who documented the issues in an internal Adobe document several years ago.)
If two fonts have the same Family and Style name, but different PostScript FontNames, both fonts are shown in the menu (an abbreviation is added to the menu to indicate font type).
When the two fonts conflict in their PostScript FontName, InDesign will never show both, regardless of format. For example, Microsoft YaHei Bold that shipped with Vista has a bug in that it has the same PostScript FontName (under some language IDs in the name table) as the regular weight of the same font. In such a case, whichever one is listed first by the core Adobe font engine will show up in the menu – in this case it’s the regular, and the bold is missing. (Yes, Microsoft has been notified of the bug, and doubtless they will fix it.)
If two fonts have the same Family and Style name and the same PostScript FontName, the following rules are followed to determine which font is used. The rules are priority from highest to lowest. If a given rule does not decide between the two fonts, go to the next rule, until one of the fonts is chosen, your brain explodes, or you run out of rules, whichever comes first.
0. Prioritize font installed in an OS font folder over font installed in a private Adobe font folder. (New rule added for InDesign CS3.)
1. Choose font that is not a bitmap font.
2. Choose font not in Adobe:Fonts:Reqrd: folder (Macintosh only rule)
This means that fonts under user control get to override fonts hidden away in Adobe’s “required” fonts folder.
3. Choose font that is not a dfont (Macintosh only rule)
This means that in InDesign, Type 1 fonts will outrank Apple’s system dfonts when they have conflicting names (as they often do). Note that this does not address the problem for other applications.
4. Choose the font with more glyphs
5. If same number of glyphs, choose the font with preferred technology using this order
Type 1 (“PostScript”) / OpenType CFF (Compact Font Format)
TrueType (including OpenType with TrueType outlines)
CID-keyed Type 1
Adobe Type Composer font
If none of these rules can be applied, then the first font enumerated by CoolType is chosen. This situation would most likely occur when the same font is resides in two separate locations. If this is the case, it will not matter which font is chosen.
Multiple master fonts contain Type 1 outlines. OpenType fonts can contain either Type 1 or TrueType outlines, and are prioritized based on the type of outlines they contain.
REGULAR AND ITS SYNONYMS
A quite distinct conflict occurs with families that have more than one member of a font family whose style is one of the following: R, Roman, Regular, Book, Plain or Normal. [Update: as Blatner points out, in CS1 this list also included "Medium," which was a big mistake.]
Basically, only one of these members of the family will show up in the font menu. Even though technically, there is nothing wrong with the font.
Why does this happen? Well, it turns out that InDesign tries to keep track of “synonyms for regular” so that when you switch the selected family, it can map from one “regular” font (by whatever name) to a differently-named one in the other family.
Which is great and often useful, except that in the current implementation, it means that InDesign can’t accept having more than one “regular” font (using that earlier list of synonyms) in a family.
Now, there are a few specific typefaces that are well-known to us, so they are hard-coded into InDesign so that it treats one of the conflicting styles as “not regular” for purposes of font switching/ID, and that allows it to co-exist with the other “regular-ish” style. Specifically, these are:
- Bodoni Std
- New Lincoln Gothic BT
If you know of other cases like this with shipping fonts, please let us know. If you’re making a new font family, you might want to avoid triggering the problem (even if we improve the behavior in a later version of InDesign, there will be a big installed base of older versions that would have the problem).
[Updated this entry 5/09/2008 to credit David Blatner and add one detail]