(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. It seems to me that the rule should be the opposite. 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). If you know of other cases like this with shipping fonts, please let us know. 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. 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. 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. Even though technically, there is nothing wrong with the font. īasically, only one of these members of the family will show up in the font menu. OpenType fonts can contain either Type 1 or TrueType outlines, and are prioritized based on the type of outlines they contain.Ī 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. Multiple master fonts contain Type 1 outlines. If this is the case, it will not matter which font is chosen. This situation would most likely occur when the same font is resides in two separate locations. If none of these rules can be applied, then the first font enumerated by CoolType is chosen. TrueType (including OpenType with TrueType outlines) Type 1 (“PostScript”) / OpenType CFF (Compact Font Format) If same number of glyphs, choose the font with preferred technology using this order Note that this does not address the problem for other applications.ĥ. This means that in InDesign, Type 1 fonts will outrank Apple’s system dfonts when they have conflicting names (as they often do). Choose font that is not a dfont (Macintosh only rule) This means that fonts under user control get to override fonts hidden away in Adobe’s “required” fonts folder.ģ. Choose font not in Adobe:Fonts:Reqrd: folder (Macintosh only rule) Prioritize font installed in an OS font folder over font installed in a private Adobe font folder. 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.Ġ. The rules are priority from highest to lowest. 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. (Yes, Microsoft has been notified of the bug, and doubtless they will fix it.) 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. 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. When the two fonts conflict in their PostScript FontName, InDesign will never show both, regardless of format. 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). (This first section owes a great debt to Michelle Hill, who documented the issues in an internal Adobe document several years ago.) The third case is a bit different, so we’ll take it separately. There are three kinds of name conflicts in InDesign that cause fonts to potentially not show up in the font menu.Ģ) Duplicate menu name (as shown in InDesign)ģ) Multiple “regular”-like styles in a single family Recently David Blatner (, co-author of Real World InDesign, Real World QuarkXPress, etc.) asked the same question, and sparked me to pull together the answers. Periodically somebody asks how InDesign prioritizes fonts whose names conflict, or what consistutes a conflict, and nobody knows.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |