InDesign Font Conflicts
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
Bitmap
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
– Bodoni Std
– Nobel
– 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]
12 Responses
Comments are closed.
Indesign CS2 (OS X 10.4.8) – Gill Sans Book and Gill Sans Regular!Font menu name Gill Sans Book but displays and prints as Regular (though not in all cases). Cannot select Regular in Menu when name is Book – but can differentiate each font if Character Style is created for each one.Baffling!,i>[Why baffling, after reading my blog post? This is a classic example of #3 above. Unfortunately, there’s no good workaround at this time, except for not having “book” and “regular” installed at the same time. – T]
We have problem with a font called Pakenham from Typodermic. We have problems with Pakenham-Book conflicting with Pakenham-Regular.InDesign will always pick Pakenham -Book over Pakenham-Regular.
It seems to me that the rule should be the opposite. (But now that it is this way already, the opposite rule should be made available as an option — or as the default, with the option to go back to the CS3 priority behavior — in future versions or updates of InDesign.)Let’s say there are two users (or two computers) — let’s call them “Designer” and “Printer” — and they are having problems with different fonts versions. Suppose that Designer wants to make sure that when Printer prints (or creates a PDF from) his InDesign document, the same font is used as what Designer is using.If priority would be given to fonts installed in the Adobe font folder, then Designer could make a package from InDesign, and Printer could just copy all the fonts in the package to the Adobe font folder. Before copying the fonts, Printer could rename or back up his Adobe fonts folder and make sure it contains only the fonts from the package. Then when done with printing or PDFing that job, he can delete the Adobe fonts folder and rename or restore the original.But if InDesign first looks at the OS fonts folder, things get much messier, because Designer will probably not want to be copying or deleting fonts in OS folder, especially if the document uses fonts that are used by other applications or by the OS.[Something like this would be a fine idea. But I’d think that the standard Adobe fonts folder would be the wrong place for override fonts. We’ve kicked around ideas like having fonts in the same folder as the document (or in some specified relationship to that location) take precedence, and I think that would work well. It’s another example of a perfectly good feature idea to weigh against a zillion other perfectly good feature ideas. – T]
“OpenType fonts can contain either Type 1 or TrueType outlines.”Can they also contain both? The spec doesn’t seem to rule it out, so what would happen? Or does this just never occur (with fonts, it’ll probably occur sooner rather than later 😉 .[In practice, it never happens. Note that while the specification does not rule it out, the accompanying “Recommendations” document makes it clear that it’s a Bad Idea. – T]
“R, Roman, Regular, Book, Plain or Normal.”I don’t understand why Book is included as a synonym in InDesign’s list. Book is lighter than Roman/Regular, just as Medium is heavier.[Hey Keith. Well, you’re in good company for believing that – Kathleen Tinkel over at dtpforums.com said the same thing. But in fact, that isn’t consistently true. It’s true for Gill Sans, for example, but the opposite is true for Bodoni (in the ATF cut, in the Adobe Type Library). Myself, I would have guessed that for typefaces with both, Book is more commonly heavier than regular. But I think it’s clearly true that most typefaces that have a “Book” weight don’t also have a distinct “Regular” weight. Not that any of this excuses what is essentially an architectural error on Adobe’s part, of course. – T]
It is always unpleasant when you think you are on solid ground but find you are on quicksand. Gives you that sinking feeling! Apparently I am wrong to believe that Book is always lighter than Roman/Regular. I must have been confusing it with Book being lighter than Medium. That said, I seem to have FontBureau.com in my corner. Check out Hoffmann, Benton Sans and Nobel. (Possibly more, I didn’t go through their whole catalogue.)
We’ve got four problem families at the Font Bureau: Benton Sans, Nobel, Hoffman, and Amplitude. (Tom, can you please make sure that they are added to the hard-code list?)[I’ll see what I can do – T]Our workaround is to send the clients a version of Regular renamed as “Regluar”; the misspelling is enough to get the fonts to work properly.We’ve also been renaming families to avoid Book and Regular combinations while the families are still in development.[Ouch! That is unfortunate. – T]As for the other thing, yes Keith, we’re in your corner. I can’t say anything official about how we name styles, but we typically use Book when the style is lighter than the Regular, but not light enough to be named Light.
I have installed a TrueType font called ‘Sanskrit Diacritics’ which doesn’t show up in InDesign CS2 but it does show up in InDesign CS3! Can’t understand because in both cases I have copied the font into the font folder inside InDesign CS2 / CS3. Can anybody throw light on this?Thanks,Sridhar[Debugging that would probably require a copy of the font. But since InDesign CS4 now provides access to the complex script layout engine (see Thomas’ post at ), I’d suggest it’s time to leave InDesign CS2 behind. – David L]
It’s 2011 now and we’re using CS4 but this problem continues to occur. I can’t tell you how many times we’ve had to deal with this issue over the years, but it’s ridiculous. At the moment we’re pulling our hair out over InDesign seeing a particular font as “Regular” and InCopy seeing it as “Medium”. All users have the exact same fonts (and versions) thanks to Extensis UTC. Is there an end in site? Perhaps the problem will go away when print publishing dies and everyone has an iPad.
Given that what you’re describing is poor application behavior, and not an issue with fonts, a more effective venue for finding a solution would be to post to the InCopy user forum. See: http://forums.adobe.com/community/incopy
If you’re unable to get anyone’s attention over there, please feel free to contact me directly.
Hello I hope somebody still comes here to take a look. Im having a font problem: I found a font I really like in Microsoft word, the name is 宋体 or Simsun in our words. When I use it in Indesign I get something completley different altough it’s the same font, copied into the adobe/fonts folder, the indesign/fonts folder from the microsoft office font folder. I have been trying all kinds of things to solve this problem but it wont change. Any ideas?
Please provide more details about the problem that you’re experiencing, because it is not clear what the exact nature of the problem is based on what you have described thus far.