Note: This applies only to OpenType naming fields only. The old-style names seem to be a messheap where no clear method works well.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

I like #2. Ambiguity sucks.

I’m feeling the same way. I think the ’best practice’ comes from past, when the longer names make for GIANT font drop boxes. I know that even the default minimum resolutions of screens has improved, perhaps it is unimportant these days.

Is there an order people prefer to read the descriptors in? Weight, width, other, or width, weight, other, or...?

Although it takes some getting used-to, I’ve grown rather fond of the three-digit description: once you master it for one font, you can translate it to others, and it certainly avoids the ambiguity.

Linda, do you mean like N0.2 above, or a numeric system?

If anyone else has any opinion, please post. I am looking for a consensus, or sorts.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

The numeric one promoted by Linotype — page 85 of my second edition of Stop Stealing Sheep (where I’ve taken the quote below) has the matrix for figuring out the weights of Univers, especially when you consider the permutations and combinations now available (59 weights plus 4 monospaced typewriter fonts!), it’s a snap to figure out which one you’ve got.

The first digit stands for weight, i.e., 1 is ultralight, 2 thin, etc., and 9 is extra black. The second digit denotes width, i.e., 1 for compressed, 2 for condensed, 3 for basic, and 4 for extended. The third indicates upright roman (0) or italic (1). Not exactly intuitive, but effective once you get used to it.

If you don’t want to go that route (I like the fact that it’s language-independent, personally), then I’d vote for your Option #2 — I’m big on keeping things as unambiguous as possible.

Unambiguous is the way I roll. #2

Eschew obfuscation!

Thank you all, very much! Clarity over brevity. I like it, and you guys prefer it. At least in PC OT-aware apps, it will all look tidy still, since the drop box of font names will boil them all down to family name, with a separate drop box for variants.

Man, I can’t wait to get this face release-worthy!

Choz Cunningham
!Exclamachine Type Foundry
The Snark

This is funny - what a great topic choice.
Personally I hate BLD — it is just one letter shy from telling it like it is...

I hate the numeric system, can never remember what weight I want. But I don’t mind the 3-letter abbreviation - it’s clr 2 me wht fnt u spc.

I DO like when the family is grouped, with drop down windows for the various weights/styles. Drives me crazy when they’re not (e.g. Klavika, altho I understand why there).

I use a different and totally inconsistent numbering system for !Square Engine, but that is specifically an homage to European motorsports. I prefer words, generally, but that is a good point about the internationalism of numbers. I might offer a Lino-numeric version of larger sets, if demand dictates in non-english markets.

Near as I can tell, in non-OpenType compliant applications, at least until Vista comes out, one can’t group sub-types reliably, aside from the Bold, Bold-Italic and Italic stylings.

However, in this case I am assuming that those who are using OT aware apps are “pickier” consumers, and they get the cleanest, most detailed, accurate names and nicest grouping (all tucked under basic face name). Similar to #2.

The non-OT apps will then show a lengthy approximation, broken into several entries, like:

[facename] [cutname]
[facename] [cutname] [width (if applicable)]
And then one would just use the “B” and “I” buttons in those sort of apps to access the bold and oblique faces.

And when Vista comes out, they will display as something confusing and different. I’ll upgrade to Vista when I am convinced it is an upgrade.

First, my answer is #2.

But at more length....

> I have read that best practices involve making stylistic components of a name as short as possible.

Says who? Why on earth would you use cryptic abbreviations except when necessary?

The rule of thumb at Adobe is to make stylistic components of a menu name as close to the way one would actually read/write it as possible, within the constraints of:

A) Maximum name lengths of different fields in the font

B) For a given field, across fonts within a family, we want to be consistent.

So for an example of (B), if for the Mac Classic menu name we are forced to abbreviate “Italic” to “It” for Expialidocious Extended Bold Italic, then we’ll do it for the Mac Classic menu names for all the italic faces in the Expialidocious family.

Cheers,

T

Even for the extra-swash alternate version? I’m assuming you’d be calling it “Supercalifragilistic”. ;-)

Says who? Why on earth would you use cryptic abbreviations except when necessary?

It’s a great site, that I can’t find my bookmark for, with a virtual course on type design. It says nothing about being cryptic, just short, and I think even those here who liked #2 could figure out the TLA’s. OT fields just don’t pigeonhole me into the Bold/Italic choice, and modern computers (that would implement OT) have resolutions of 1024*768 and up commonly.

In the “classic” name fields, everything will look about the same, except that I substitute “Italic” for “Oblique”, as it rumored that people may have problems otherwise.

- Or -

I would! On !Square Engine, the cryptic abbreviations are totally gratuitous fun.

—
They way adobe does fonts is really great to know. It isn’t simply the scale of them and their output, but things like you communicating the tech philosophies that makes them a standard-bearer. Free dev tools help too! ;)
—

Without a mac in the house these days, I am not sure how they render font names outside adobe apps (which, I imagine are almost identical in this to their PC equivalents). I’m guessing something more advanced than 2K/XP. From what I’ve seen, however, everyone with a pre-OSX machine understands that it might not be 100% cool with modern software. Well, actually I don’t know anyone anymore with a pre-OSX machine. Does anyone have experience or a white paper about OSX default name display?

For godsake, #2!

Choz: Thanks for the kind words. So, with your OS X question, is this for OpenType and/or TrueType, or for Type 1 fonts?

The other variable is whether it’s apps using the new “Fonts Panel,” or other (non Adobe) OS X apps.

T

#2 for teh Win, it is decreed!

Thomas.
At this point I am only focused on OpenType (TrueType flavor). I have a feeling it will be around a long time, and I adore the potential of OT typographical features. These fonts seem to fall back to TrueType name fields in older style apps. Well, actually they seem to fall down like matchstick men in a wide range of assorted PC apps.

My short answer is, if you’re using FontLab, use the naming process outlined by Adam Twardoch and all will be largely well. http://groups.msn.com/FontLab/tipsandtricks.msnw?action=get_message&mvie...

Gruesome details on OpenType and TrueType name IDs:

So for TrueType, OS X will use the Mac name IDs 1 and 2 for apps using the fonts panel. If you don’t do anything special in FontLab, these will be set the same as their Windows equivalents, and you’ll be stuck back at the four-member family model. (But there’s another option, so keep on reading.)

Apps getting “Classic” menu names will use Mac name ID 18 if present. (FontLab’s “Mac Name” under “OpenType-specific names.”)

Adobe apps use Win name IDs 16 and 17 on both platforms. We consider those the typographically savvy names. (In FontLab: OT Family Name and OT Style Name.)

Note that if name IDs 16 and 17 are not present, name IDs 1 and 2 get used instead. So if they’re the same, they can be omitted. (FontLab does this automatically.)

Note that in Adobe fonts, Mac name IDs 1 and 2 usually correspond to Win name IDs 16 and 17. However, 16 and 17 have a slightly longer length limit than 1 and 2 (I think it’s 63 or 64 characters, instead of 31 or 32 characters). FontLab can set this up automatically if you check the option under “Generating OpenType & TrueType” for “use the OpenType names as menu names on Macintosh.”

Well, I hope that was involved enough!

Cheers,

T

How does Adobe get “Adobe Garamond” to position itself in CS menus under “G”?

under “G”?

Good one. Inquiring minds want to know...

Upon finally getting around to a close inspection of the Adobe Garamond Pro PostScript OpenType (OTF), I have no idea. No idea at all. All the tables seem to populate normally, and it should position in the A’s. My ability to inspect a PostScript is, however, severely limited, as my knowledge and tools are all TT oriented.

I am even becoming suspicious that it is a application-side hack now.