Naming, grouping conventions for large family

Cory Maylett

I have a condensed type family with nine weights in each of three widths.

I'll be releasing the entire thing as one large variable font and as individual fonts. In addition, it seems to make sense to release the three widths separately as sub-families — each having their corresponding nine weights.

The primary audience for this family would be graphic designers (both web and print), although I can't rule out the occasional MS Word or Publisher user.

My preference would be to give the entire family the same name, then use the name of each individual font to differentiate the widths using numbers instead of the more traditional thin, light, bold, medium, x-bold, etc.

For example:

     Fontname X-Cond-300
     Fontname X-Cond-600
     Fontname Cond-300
     Fontname Cond-600
     Fontname Narrow-300
     Fontname Narrow-600

This naming scheme is unusual, but it's straight-forward and mimics CSS weight designation conventions. It would also bundle everything into one nicely ordered menu listing in Adobe CC and my other Macintosh application. I'm less sure about Windows. I'm also concerned about those applications that artificially bolden or slant type when it can't find the right fonts after the user clicks the B or I buttons for that sort of thing.

Given the target audience for this font family, I'm not too concerned with ancient versions of MS Office applications, but on the other hand, if breaking up the fonts into three separate font families and giving them more traditional names will make things more Windows compatible, it might be best to do that.

So I guess my question is whether or not I'm cluelessly considering a stupid idea. If so, any suggestions? What am I overlooking?

Thomas Phinney

You say widths, but it sure looks like you meant to use the numbers to designate weights, perhaps?

You don't define what you mean by “separate font families.” To me, this means that the family name and grouping is distinct, in ALL apps.

Modern Windows apps don’t use the legacy Windows families, and can use the same typographic family as your fancy publishing and web apps. You can include legacy Windows family info for the old apps, without affecting the newer apps.

You can style link fonts, and still have additional fonts be members of the same typographic family. You can even have more than one style-linked set in a single family.

You can have fonts not be style linked, but still show up as a single family in more sophisticated apps, including recent versions of Microsoft Office. However, if you use bold and italic style links, those style-linked fonts will need to be members of the same family, in all apps.

All but the high-end print publishing apps will artificially bolden or slant type if you don’t have the style link info in the fonts and the user attempts bold or italic styling. This includes web apps. So, I wouldn't omit such style links entirely, if I were you. At least, make sure they work for "regular" to "bold" and that "italic" always works (assuming you have italics, you were not explicit, maybe you don’t).

Cory Maylett

Thank you Thomas.

Yes, I mean 9 weights in each of three widths, which is what I wrote (I think, unless I'm misreading my own writing, which I've been known to do).

I'll try to rephrase with example names:

Option 1 (the one I prefer)

     Albireo  X-Cond-100
     Albireo  X-Cond-200
     Albireo  X-Cond-300
     Albireo  Cond-100
     Albireo  Cond-200
     Albireo  Cond-300
     Albireo  Narrow-100
     Albireo  Narrow-200
     Albireo Narrow 300 (and on up to 900 in all widths, including italics)

Option 2

     Albireo-X-Cond  Thin
     Albireo-X-Cond  ExtraLight
     Albireo-X-Cond  Light

     Albireo-Cond Thin
     Albireo-Cond  ExtraLight
     Albireo-Cond  Light

     Albireo-Narrow  Thin
     Albireo-Narrow  ExtraLight
     Albireo-Narrow  Light (and up to black at the other end including italics)

In other words, the first option keeps all the weights and widths together in one big menu. The second option splits the weights apart into three separate width families that would show up as three separate menu listings.

You answered some of my questions, but I'm running into issues with the first option in getting linked regular, bold, italic and bold italic styles to actually link when the B an I buttons are clicked in MS Word for Macintosh. Instead, they're being artificially bolded and slanted. I assume similar problem in Windows Office but only have an old XP laptop for testing. Then again, in the first option, there are three separate bolds, italics, regulars and bold italics without traditional names, but still linked.

I haven't tested every permutation of this yet, like breaking the family into the three separate widths and using standard names, but I've not run into this problem before. Then again I'm using Glyphs this time around whereas I used FontLab V previously. I suppose it could be a Glyphs problem, but I strongly suspect it's a me problem.

Cory Maylett

Claudio Piccinini

I was about to ask a similar question, but for a simpler problem, so if it’s not a problem I’d just add here instead of opening a new discussion.
I thought it was preferable to avoid numerals in names, isn’t this no longer a problem, @Thomas Phinney?

My general choice would be to use two/three digit abbreviations to classify point sizes, i.e. TX for text, TL for titling. But since, in titling sizes for example, I might have two or three different point sizes (corresponding, let’s say to 48pt or 72pt) I was thinking if it was fine to follow Cory's strategy and use:
– Facename TL48
– Facename TL72
or
– Facename TL-1
– Facename TL-2.

Here the numerals would be important, as I am not addressing just weights like Cory.

Thomas Phinney

If I follow your intentions, personally I would go for keeping them all in one family. I have rarely seen them split.

Adobe split their recent neogroteque, Acumin, into separate families by width. But it has 90 styles, rather than 27, so it is a more extreme case: the benefits of splitting are more apparent.

Even so, with Acumin, in actual use, I have had trouble with it because of this production choice. When changing between font families, as I can't do a simple “switch” from another family that has all the widths integrated into one family, to Acumin, in InDesign—Acumin defeated this by effectively being several separate families, and I found it quite irksome.

* * * *

On the side, I find the hyphens in your names distracting and odd. What’s up with that?

Also, I am not a fan of using numbers for the name-labels of the weights. The weights have these numbers internally, and if an app wants to expose them, it can. Adobe apps use the fonts’ internal weightclass numbers for sorting the font styles, so as long as your fonts are built properly, they will sort nicely in Adobe apps (and other apps smart enough to do the same thing)—without you sticking numbers in the names.

Claudio Piccinini

Thomas Phinney said:

Also, I am not a fan of using numbers for the name-labels of the weights. The weights have these numbers internally, and if an app wants to expose them, it can. Adobe apps use the fonts’ internal weightclass numbers for sorting the font styles, so as long as your fonts are built properly, they will sort nicely in Adobe apps (and other apps smart enough to do the same thing)—without you sticking numbers in the names.

@Thomas Phinney: I agree about your suggestion on weights – how about my question about using numbers in the Family name for different point sizes of Titling, Subtitling and/or Text styles or is that a technically wrong or deprecated practice? I see there are even old typefaces (e.g. Wingdings) which use them.

Artur Schmal

My personal preference is to place attributes like width and titling/text in the the familyname, and only the weight in the stylename. It tends to give less font naming headaches.

Craig Eliason

"Yeah, I tried the numbers thing, didn't catch on." -- Adrian Frutiger

Thomas Phinney

You can certainly use labels like "72 pt" and "12 pt" for different intended-size usage.

Although I am personally used to, and fond of, the word-based labels for this purpose, I think that in this case the numbers will likely communicate better to the average user.

Plenty of people have no idea what usage might be intended by labels such as “display” or “caption,” I am sure. I have seen them mis-used even in a situation where you would have thought the user surely would have known the right thing. If Adobe’s own staff couldn’t get that right in an internal design contest, what are the odds a random collection of designers will get it?

I hate when the thing that somehow feels right to me personally (namely the word-based labels) is probably objectively a poor choice. (sigh.) But as a detective I have to go where the evidence leads, whether I like it or not.

Of course, we haven't seen actual results of comparative testing of the two options, here. Mine is but an educated guess, having seen that one option works poorly. Anybody happen to have data on that?

Claudio Piccinini

Thanks much everyone!

Artur Schmal said:

My personal preference is to place attributes like width and titling/text in the the familyname, and only the weight in the stylename. It tends to give less font naming headaches.

Yes, I entirely agree. That’s what I was intentioned to do, and would prefer, but you’d be limited to a single version for either Titling or Text.
e.g.
– TypenameTL Regular
– TypenameTX Regular

Thomas Phinney said:

You can certainly use labels like "72 pt" and "12 pt" for different intended-size usage.Plenty of people have no idea what usage might be intended by labels such as “display” or “caption,” I am sure. I have seen them mis-used even in a situation where you would have thought the user surely would have known the right thing. If Adobe’s own staff couldn’t get that right in an internal design contest, what are the odds a random collection of designers will get it?

Encouraging… 

Well, I could go this route then:
– Typename72pt Regular
– Typename48pt Regular
– Typename12pt Regular
– Typename 8pt Regular
or
– TypenameTL1 Regular
– TypenameTL2 Regular
– TypenameTX1 Regular
– TypenameTX2 Regular

Still unsure…

Claudio Piccinini

This devanagari typeface apparently uses numerals in the family name (714)…

Cory Maylett

Thomas Phinney, There will be 72 separate fonts in the family I'm finishing up (although I might leave out the 100 and 900 weights), which makes for a rather long drop-down menu. So yes, I too was paying attention to the way Adobe handled some of their recent large font families, and it, in part, is one of the things that prompted my questions.

You asked about the hyphens in the names. I won't be using those hyphens in the actual names. I only used them here, in this forum, for clarity in differentiating between the family and individual font names.

As for using numbers instead of names for the weights, a big part of my day job consists of designing website interfaces, so I've become comfortable thinking in terms of CSS numerical font weight attributes. After this discussion, however, I'm leaning toward using the traditional names. Most print designers would still regard numerical names as odd and, possibly, confusing.

Artur Schmal, your reference to Adrian Frutiger is interesting since it has also been in the back of my mind. I'm not sure I ever did wrap my head around Univers' numbered names and what they meant. I don't want to repeat his mistake, but like I mentioned above, Cascading Style Sheets have made numbered weights more or less the norm — at least for web coders. Whether or not this will ever catch on with print designer, I don't know. I suspect not.

Anyway, thanks to both of you. I really appreciate you helping me think this through and sharing your knowledge. It has helped!

Thomas Phinney

72 styles is a lot, indeed. I don’t think Adobe’s choice for Acumin was crazy; I just wonder if the particular problem I had with it was not one they thought of. It is entirely possible they considered it a reasonable compromise/tradeoff.

Personally, I prefer to have my families all work the same way, and not have one split up because it has too many styles. (But I wouldn’t know this without having worked with something else for a while.)

Understood on the hyphens. And yeah, I think “old school’ designers who have less exposure to the numeric weights might find them inscrutable. But there are fewer of them every year.

Claudio Piccinini

Thomas Phinney said:

Understood on the hyphens. And yeah, I think “old school’ designers who have less exposure to the numeric weights might find them inscrutable. But there are fewer of them every year.

May I ask where do these numerical values come from? From web typography?

Thomas Phinney

Originally from the usWeightClass in the OS/2 table of the TrueType specification, which was inherited by OpenType. See https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass

Later, that scheme, including the numbering system, was adopted by the W3C for CSS. This adoption exposes them to web designers in a way that print designers never saw them. That, combined with the advent of web fonts that may have a wide range of weights, has much increased the visibility of these numbers.

The initial version of usWeightClass adopted by the W3C was restricted to pre-determined values (the same nine hundred-unit increments that get labels in the spec), despite being informed this was a Very Bad Idea, that was already contradicted by plenty of shipping fonts. Years later they updated their version to explicitly allow other values.

Claudio Piccinini

@Thomas Phinney: Thanks much for the insightful and concise reply as usual.

Cory Maylett

@Thomas Phinney said: Personally, I prefer to have my families all work the same way, and not have one split up because it has too many styles.

@Thomas Phinney said: Later, that scheme, including the numbering system, was adopted by the W3C for CSS. This adoption exposes them to web designers in a way that print designers never saw them.

Sorry to resurrect this thread, but speaking of CSS and keeping multiple widths grouped within one font name, wouldn't this cause a CSS issue?

When the CSS font-family property is set and the font-weight property set to, say, #600, how would the browser know which width in the font-family to call up? Would it call in the extra-condensed 600 weight, the condensed 600 weight or the regular 600 weight?

In other words, for example:

h1 {
    font-family: xyz;
    font-weight: #600;
}

If there are multiple widths in the family with the same weight, how would the browser differentiate between those weights (assuming they were all present) when there's nothing in CSS to do so?

I'm feeling a bit burned out today, so maybe there's an obvious answer that will seem clearer in the morning.

Thomas Phinney

I would expect the browser or other CSS parser to default to normal/regular width (5), in the absence of any other input.

Cory Maylett

Thank you, Thomas. I had somehow forgotten that fonts widths had numerical values similar to the weights. There's also the not-often-used font-stretch CSS property that, despite its name, doesn't stretch the fonts. Instead, it uses values, like condensed and expanded to identify the right width when multiple widths are present.

I knew I had overlooked something simple. Asking the question here combined with a mind-clearing walk around the neighborhood with our dog straightened it out. Again, thank you.

Thomas Phinney

I am a big fan of pet therapy. Often underrated.