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.

(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]

"Create from scratch, the typographic love child of:
Garamond and Zebrawood"

See what Christian Robertson and other type designers came up with, on Typophile.

No, it's not April 1st any more, and I couldn't make up a story this good. I got tipped to it from this article in Gizmodo.

Basically, in Turkish the dotless i is a different character than the i with a dot. Incorrectly leaving the dot on in displaying an SMS message from another cell phone led to a misunderstanding which culminated in a self-defence killing and a suicide.

Reportedly, most cell phones in Turkey don't support the dotless i (which in the article is called a "closed i" - I'm using the font geek term instead).

Now, one might wonder why the cell phones lack Turkish localization support. Is it because of the expense of localizing (tailoring to a specific market) or globalizing (supporting more or all markets)? Are many Turkish cell phones grey market imports because they can be had cheaper that way?

Even if all cell phone companies were to localize their Turkish offerings, the same story could have happened with Turkish immigrants living in another country. In a perfect world, we would have cell phones everywhere that supported all the world's languages. Of course, that's not about to happen any time soon.

But at least it helps raise awareness of the issue, and perhaps more folks will think about how much language support they can squeeze into a product, and the costs and benefits of doing so.

We'll have to wait until May 8th to find out if it wins. In the meantime, note that you can vote yourself for the "People's Voice" awards in each category. For example, to vote on "Best Use of Typography," go to the main People's Voice page, then navigate to Web Sites > Features > Best Use of Typography.

Then, we learn that Erik Spiekermann has been knighted by Queen Elizabeth II.

In related news, today is also the 8th anniversary of The Guardian's "Return to San Seriffe" article. For more about this amazing island nation, see Wikipedia.

On a day like this, I start to think anything is possible!

We have a bunch of icons which are used on the Adobe web site to identify different character set coverage and the presence of various OpenType typographic goodies in our fonts. A year or two ago I mentioned that we would be happy to share them with other font vendors, and a few people wrote me to take me up on my offer. But we've updated the icons since then. Now I'm able to offer for download not only the GIF files, but also the outline fonts we used to create them, and a useful readme about the icons.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

As long as you agree to the terms, you can simply(download the Zip file.

Have fun!

[UPDATE March 27th: Deadline extended to Monday, April 14th.]

For the TypeTech Forum section of the conference, I also welcome any proposals for longer workshops, say half-day or full-day, if the topic will be of interest to a sufficient proportion of font developers.

Although the discounted hotel rate ($79 at the Fairfield Inn) was to expire today, I hear through the grapevine that it's being extended to end of day Monday!

For more details, including a full schedule, see the Microsoft Typography site.

I live just a short drive away, so of course I'll be there, including being on a panel or two.

By family (PDF)
Individual fonts listing (text)
Both by family and font (Excel spreadsheet, see both tabs)

I really enjoyed working on this with the good folks from the AIGA. They had a strong vision of what was needed, and we were able to work with them to figure out how best to implement it.

We do have another education package, the little-known Type Classics for Learning. This is also some 500 fonts, and is only $99, or about $50 for large-scale licensing (e.g. a classroom). However, trying to keep the price to an absolute minimum restricted which fonts we could include in that package, due to royalty issues. That's great for really tight budgets, but for students and institutions that can afford the slightly higher price of Font Folio Education Essentials, I think it offers a much more rounded collection including more "big name typefaces."

The first is pretty serious. Set text above 64 point in an OpenType CFF font, and it all munges together, overlapping. It's basically unreadable and unusable at these sizes.

The latest Windows PowerPoint hotfix fixes these issues, hurrah! However, it has not yet been rolled up into a regular update, because it has not been as fully tested as everyone would like. It definitely solves the problems noted above. If you are encountering these problems and need them fixed *now* and are willing to take a slight chance, then you should download the hotfix. To get the fix now, rather than waiting, you can request Hotfix SRZ071022000448. [added info 17 Mar 2008:Microsoft's writeup is now available in their Knowledgebase article 948941.]

Otherwise, you should wait for this to be rolled into a regular update (available through the Microsoft Update service), or a later Service Pack update. I'll post when the "regular" update is available.

What we're concerned about is overwrite behavior. Up to and including the CS3 applications, we have always blindly overwritten any identically-named font files with the versions in the installer. Usually this results in newer fonts being installed over older ones. On some occasions, this could have some kind of compatibility impact. We expect noticeable document reflow to be very rare, but doubtless it will happen in some cases.

We're particularly interested in this right now because we updated virtually all Adobe fonts last fall, after the CS3 versions shipped. The changes were pretty minor, but some will increase compatibility with future applications, and others could cause reflow in some cases.

To give one example, we enabled support for arbitrary fractions such as 13/79 in several typefaces, such as Chaparral Pro. If a user had applied fraction formatting globally, normal numbers would end up getting superscripted, and certain combinations that might be intended in some other way would get treated as fractions, and numbers by themselves would get superscripted. So Of course, Adobe's User Guide for OpenType fonts specifically advises against global usage of fractions or superiors formatting, but one has to assume a few people will do it.

We have two possible behaviors for the future. In both cases, the installer checks for duplicates, and if any of the fonts being installed match fonts already in the install location but are a different version, either the old or new duplicates are moved to a new location, and a readme file is created on your desktop with the details. (If there's no conflict, there's no readme.)

Note that all behaviors in question are for Adobe applications which can be licensed as part of the Creative Suite. They do not apply to large font collections such as Font Folio, as these do not have installers.

Click Here to take the survey about font installation.

Amanda Paull from Extensis tried to post this as a comment, but it's too cool to hide away like that. :)

"Thought your readers might have some fun with this on Valentine’s day: its a font matching/ dating game thingy. Hard to explain, but a fun diversion for font fanatics..."

If you're interested in the mailing list:

subscribe: opentype-migration-sub@indx.co.uk
unsubscribe: opentype-migration-unsub@indx.co.uk
messages: opentype-migration-list@indx.co.uk

Here's the text of our posts, with handy links.

A draft of version 1.5 of the OpenType spec has been posted for review here:
http://www.microsoft.com/typography/otspec150/default.htm

A summary of the changes can be found here:
http://www.microsoft.com/typography/otspec150/changes.htm

We’ve posted it in an unlinked location so that the community can review it for any typos, errors or omissions – changes from 1.4 are highlighted in color (red and blue). Once we’re happy with it, we will post it alongside version 1.4 on the main site.

Our goal with 1.5 was to reflect changes implemented in the most recent versions of Unicode as well as Microsoft and Adobe’s software and fonts. Because of this we’ve already started work with our colleagues at Adobe on version 1.6. Tom Phinney will be sending out a list of what’s in the works along with a call for ideas for the next update, which we hope to finalize in the coming months in order to meet ISO deadlines.

I’d like to thank everyone at Adobe and Microsoft who’ve worked on this over the past few months. In particular I’d like to thank Michelle Hill who’s been coordinating the effort.

Please direct any corrections to mihill at microsoft (with a dot-com on the end). Note that for some reason the PDFs are not working, but these remain unchanged from OT 1.4.

I added:

Now that we have a solid draft of the OpenType 1.5 spec, we're also
soliciting your ideas/proposals for OpenType 1.6.

Generally, the best way to propose something new for OT 1.6 is to post
it to the OpenType list. If for some reason you want private feedback
first, you could send it to me and Si.

Ultimately, we'll need any proposal in full formal spec language.
However, it may sometimes be useful to kick around the general concept
on the list first. If you aren't yourself up for writing up your idea in
the standard spec language, you'll need to find somebody who is; either
Microsoft or Adobe may adopt your idea to move it forwards, or perhaps
you can find some other interested party.

Besides a host of colleagues at Adobe and Microsoft, I'd like to
especially thank Sairus Patel here at Adobe, who has been the lead
technical person for both the 1.5 spec and potential 1.6
changes/additions.

For your reference, here are some things already being considered for
the OpenType 1.6 spec:

New Features:

1) Changes to stylistic sets feature to support human-readable named for
the sets, in any language(s). Considerable thought has already been
given to this, with an initial proposal from Adobe and a
counter-proposal from Microsoft, but it still needs more work, so it
didn't make it into 1.5.

Other clarifications:

2) Clarify TrueType instruction handling relating to INSTCTRL and
GETINFO.

3) More clarifications in the 'name' table

For "Recommendations":

4) Add info on how to detect and process the incorrect 'size' feature
structures put in a bunch of Adobe fonts.

5) Add info on what names should get put into formatting markup

6) Add more info on how the line height should be computed given the
addition of bit 7 in the fsSelection field of the OS/2 table

7) Consider having the recommendations given for "First Four Glyphs in
Fonts" apply to the C1 control characters.

Currently none of Adobe's western fonts support this functionality. There are several reasons for this:

1) Prior to InDesign CS3, none of Adobe's flagship creative graphics/publishing applications supported mark attachment in the regular western version.

2) Adobe's FDK (and thus FontLab) don't yet support mark attachment, so it was not easy for us to do in OpenType CFF fonts.

3) it's more challenging to do the contextual kerning required to kern these dynamically combined accented letters.

So, with InDesign CS3 out, we now have an Adobe app that can use this functionality.

Moving forwards, for most of the language support we have done before, we will continue to use prcomposed accents. But for more extended language support, which we are starting to work on now, we will use OpenType mark attachment ('mark', 'mkmk' and 'mlig' features as appropriate).

As you might guess from that, we'll be enabling this by adding support for mark attachment to our own Adobe FDK for OpenType, which also yields source code for FontLab and DTL FontMaster. I can't give you a clear timeline, but I'll say that the fact we want to use the functionality ourselves increases the priority of getting it into our tools.

The results shown below are based on the first 165 responses. I may update the results in the future if I have a lot more responses and the results change noticeably. You can also download an Excel spreadsheet of the survey results, if you'd like to look at the numbers more closely.

For each question, there is a graph of results, followed by summary and then comments.

Q1. How important is each of these factors to you in terms of the selection of fonts that is available to you for use on the Web?

• Encouraging everyone to use free and open source fonts (29% said "critical" or "very important" / 47% said "not very important" or "irrelevant")
• Restricting Web font usage to free and open source fonts, as a way of encouraging everyone to use free and open source fonts.
  (12% said "critical" or "very important" / 75% said "not very important" or "irrelevant")
• Being able to use the same fonts for the Web that I do for print.
  (65% said "critical" or "very important" / 9% said "not very important" or "irrelevant")
• Being able to use the same fonts on the Web that are part of an existing visual identity (81% said "critical" or "very important" / 7% said "not very important" or "irrelevant")
• Being able to use common retail fonts (65% said "critical" or "very important" / 12% said "not very important" or "irrelevant")

Q1 comments: This was a general question about what factors users care about in terms of what fonts they'd be able to use. Seems like the bottom line is they want to be able to use the fonts they want to use, especially the ones they are already using elsewhere for the same purpose.

Q2. How well would a web font scheme meet your needs as a web designer/producer if:

• You could ony use fonts that are legally allowed to be freely redistributed? (Free fonts, some shareware fonts, no retail fonts, no fonts that come with common retail applications or operating systems: maybe 3-5% of all the world's fonts) (15% said "superbly" or "well" / 66% said "poorly" or "not at all"
  
• You could only use fonts that have embedding bits that allow preview/print embedding, and whose license terms allow such usage? (Maybe half of all fonts). (54% said "superbly" or "well" / 17% said "poorly" or "not at all")

Q2 comments: This boils down the previous question into which fonts each proposal would allow. What's most interesting here is what's implied but not stated (because I didn't ask the question): what users really want is to use any font. Even being able to use about half of all retail fonts Is still not perfect - although massively better than being restricted to free and open source fonts.

Q3. How likely would you be to do each of these things when using fonts on Web pages under one of these proposals? (Please be candid; remember, this survey is anonymous!)

• Check the font license (EULA) to be sure it was allowed to be used in this way, even if it worked. (56% said "always" or "usually" / 30% said "rarely" or "never")
  
• I'd just use whatever fonts would work, regardless of the license. (26% said "always" or "usually" / 55% said "rarely" or "never")
  
• If a font didn't work automatically, if I found a utility that allowed me to modify the font to make it work, I'd use it - even if that might not be legal. (13% said "always" or "usually" / 74% said "rarely" or "never")
  
• If the font license (EULA) terms for Web usage were unclear to me, I'd just use the font. (38% said "always" or "usually" / 41% said "rarely" or "never")
  
• If the font license (EULA) terms for Web usage were unclear to me, I'd contact the licensor for clarification. (24% said "always" or "usually" / 51% said "rarely" or "never")

Q3 comments: This question is trying to survey users about behaviors that retail font developers are likely to be concerned about. I thought it was interesting that most users claimed they'd check the font license, although many would just use "whatever fonts would work." Even with a utility to make it easy, only a minority would go so far as to hack the fonts - and differences in responses makes it clear that if hacking a font was required to make it work, that would deter a noticeable chunk of people who couldn't be bothered to check the license to see if usage was legal. But font vendors need to make their licenses clear on these points - a lot of people would use the font if they weren't sure what the license allowed, and most aren't eager to contact their font vendor for clarification.