Posted by David Lemon

 Comments (9)


November 3, 2011

The Adobe Type team has been wrestling a bit with Shakespeare’s timeless question as we wrap up some newly-enhanced typeface families here.

When we make changes in a typeface that could cause  line lengths different from those produced by the previous version, we believe it’s necessary to change the font name a bit so the two versions can’t be accidentally swapped and reflow people’s existing documents. We usually do this by changing suffixes.

Std & Pro
One of the biggest changes we ever made was moving the Adobe Type Library into the OpenType format (starting in 1998). We figured the best way to preserve some continuity yet differentiate the new fonts was to add a suffix to each font’s name. Fonts with our Western European character set would get a “Std” suffix, while those that also supported the Central & Eastern European characters would get a “Pro” suffix. Today it’s simple to look at any Adobe OpenType font name and know whether the font’s language support goes beyond Western Europe. (Our East Asian fonts are a different matter, and have their own character collection suffixes.)

Although we explained the guidelines for our naming convention, some font developers chose to use our Std and Pro terms to mean something else. Thus a Pro font from a non-Adobe source might not include a single CE character. We think this is pretty confusing for our users. If we had the chance to do it over, we might not have used suffixes at all; perhaps we could’ve found a better way to differentiate OpenType names from Type 1 names. But now it’s too late to change the current names, because existing documents wouldn’t recognize the new names. That kind of change is necessary when the fonts themselves have changed, but we can’t inflict that amount of incompatibility on people just to clarify a naming convention.

What’s next?
Over the years we’ve moved a few families (like Bickham Script) from the Std character set to Pro, and of course we added a lot of other features along with the language support. Now we’ve added still more characters and cool new features to a handful of families that were Pro fonts to start with. It would be even more confusing if we kept making up new suffixes – what would come after Pro? And what would eventually follow that?

In the end, we can’t keep designating ever-bigger character sets with suffixes. You’ll soon see some Adobe Western fonts with numbers in their suffixes. The new fonts will still be Pro, but now the “Pro” will be followed by the major version number of the font. We re-set most of the fonts to version 1.0XX in the OpenType conversion, and moved most of them to version 2.0XX in our first set of major updates. When we make further big changes, the updated fonts become version 3.0XX – and their suffix will be Pro 3. Watch for it in an upcoming release!

[updated to correct version info]


  • By Stephen Coles - 5:41 PM on November 3, 2011  

    Fonts have always had version numbers, but they were essentially invisible to most users, so I totally understand the motivation to surface the major upgrades in product names. I just hope these version numbers don’t appear in marketing and editorial content that refers to the design of the typeface. Too often, folks refer to “Trajan Pro” when really they’re talking about the shapes of “Trajan”.

  • By Dave Pawson - 11:13 PM on November 3, 2011  

    “we believe it’s necessary to change the font name a bit so the two versions can’t be accidentally swapped and reflow people’s existing documents. We usually do this by changing suffixes.”
    Being Adobe, I guess you couldn’t follow the rest of the (software) world and use version information in the otf file?
    [David L: Of course the version numbers are stored in the version field of the fonts' 'name' table. But for better or worse, no application I know of stores a font's version information in documents. App's simply store the font name. So when two versions are substantially different, using identical names would cause unexpected changes in documents if/when the user changed font versions.]

    • By John Hawkinson - 11:10 AM on November 14, 2011  

      David: “no application I know of stores a font’s version information in documents.

      InDesign does! Visible in Type > Find Font

      • By David Lemon - 2:22 PM on November 14, 2011  

        That’s great; we’ve been asking app’s to do this all along. Now we just have to get all the other app’s you’re using to do the same…

  • By Erik van Blokland - 11:32 PM on November 3, 2011  

    Numbers would at least imply some sort of order. I know Linotype’s “neue” / “next” / “nova” scheme isn’t always as clear. Thanks for posting, David.
    [David L: I was just talking about this with a co-worker. What would come after "next"?]

  • By John Hudson - 1:19 PM on November 8, 2011  

    Historically, I recall, Adobe were reticent to use numeral characters in font names, and I presumed there was some reason for this related to possible bugs in menus. Is this now considered safe?

    • By David Lemon - 1:39 PM on November 8, 2011  

      That’s an interesting piece of arcana. The issue with numerals had to do with an interaction between the PostScript name (aka FontName) and the Macintosh file name of a Type 1 font. The Mac names had to be a truncated version of the FontName: The first “word” was truncated to its first five characters, and each subsequent “word” was truncated to its first three characters. The OS connected the font file (LWFN) with the metrics file (FOND) by recreating that truncation, so the two had to match. The tricky bit was that “words” were identified as anything beginning with A-Z – so numerals were thrown away by the truncation. Since those were normally there to differentiate fonts, this defeated the purpose. Now that we’re in an OpenType world, this isn’t an issue.

  • By Andrew Dunning - 7:18 AM on November 11, 2011  

    It’s very good to know that you’re continuing to improve your typefaces, which are already fantastic. While you’re at it, could you consider a specific request? Angle brackets are very necessary in printing classical texts, in textual criticism, and a number of other applications. Because they’re not included with most fonts, however, they tend to really mess things up when they’re used; many publishers end up resorting to greater-than/lesser-than signs, which looks terrible. Even when a printer goes to the trouble of substituting a proper one (i.e. U+27E8 and U+27E9 or U+3008 and U+3009) from another font, it’s often of the wrong weight and spaced poorly. If you could add real angle brackets to Minion (and ideally Garamond Premier, Arno, and Myriad as well), you would be doing a huge service to the world.

    • By David Lemon - 10:05 AM on November 11, 2011  

      Thanks, Andrew. We’re in the process of extending a few families to cover a very large character set. I see that doesn’t currently include the angle brackets, so we’ll look into that.