Condensed Light vs. Light Condensed

Ray Larabie

I grew up with fonts described as weight, followed by width, and optionally italic. For example, in my Letraset catalog, it's Microgramma Bold Extended, Helvetica Light Condensed, and Folio Bold Condensed. But these days I think it's more common to see width followed by weight. Looking at the MyFonts bestsellers list: Helvetica Neue, Gotham, and Avenir are width/weight, while Frutiger, Helvetica Pro, and Trade Gothic are weight/width.

Is there an advantage to either format? I noticed it's the default in FontLab 8. I've tried it both ways, and they seem to look okay when they're listed in font menus.

The weight and width order is something I hadn't even though about until recently. I always made my fonts width/weight because that was what everyone else making fonts seemed to be doing.

Cristóbal Henestrosa

I think the main difference comes with numerous families like Acumin and its 90 styles: five widths and nine weights, all with italics.

It would be complicated for the user to manage the 90 styles into one single family, so it is wise to divide it in several subfamilies, and the width is a good way to do it. At least it is how I’d do it.

So you have:

—Acumin Extracondensed,

—Acumin Condensed,

—Acumin Semicondensed,

—Acumin (normal width),

—Acumin Wide.

And, just after that, you have nine weights for each width:

—Acumin Extracondensed Thin,

—Acumin Extracondensed Extra Light,

—Acumin Extracondensed Light,

—Acumin Extracondensed Regular,

—Acumin Extracondensed Medium,

—Acumin Extracondensed Semibold,

—Acumin Extracondensed Bold,

—Acumin Extracondensed Black,

—Acumin Extracondensed Ultra,

&c.

If the family is not that big, I guess you can go both ways.

Thomas Phinney

Acumin is split up into subfamilies. Even with proper typographic families enabled, for the non-variable version, each width is a separate family. Hence the unusual (for Adobe) naming order.

Adobe’s standard was or had previously been generally the other way around, however.

That is still my preference, but doubtless influenced by the Adobe practice on this... although the current generation of that, I was involved in. I remember sitting at a table in a meeting room hashing out what would be the standard on this moving forward, too. Both for Adobe Type Reunion style code baked into CoolType (used to handle family/style display in Adobe apps such as Photoshop, Illustrator and InDesign), which mostly Sairus Patel and I worked out (likely with input or review from David Lemon, maybe Christopher Slye, possibly others); and then leveraging that, in turn, for figuring out what we were doing in the “preferred” font style names for OpenType fonts, including those converted from legacy Type 1 fonts. ~ the same answers.

I understand why the massive size of the Acumin family caused them to do this crazy split, but the inconsistency with other fonts, and the fact that the family styles fail to map to other families as a result, etcetera, makes me really wish they had maintained consistency, rather than doing something different because they thought it would be better for this family.

Kent Lew

Font Bureau settled on width then weight for the reason that Cristóbal mentioned, to make more sense when split up into subfamilies. 

I don’t know if there was any internal debate. That scheme was inherent in the original Bureau Grotesque, with its funky numbered styles — e.g. Five Three versus Three Five. And then it was made explicit when harmonized into Bureau Grot.

Dividing subfamilies by width made more sense when managing large families like Benton Sans and Titling Gothic, et al.

Mark Simonson

I’ve used this width first strategy for Proxima Nova and other families from the beginning, dividing into subfamilies, even though it goes against tradition just because it makes the font menus easier to navigate.

Craig Eliason

I’m far more likely to change the weight within a consistent-width stretch of text than to change the width within a consistent-weight stretch of text. So in that respect weight feels more particular and thus lower in the hierarchy. Another way of saying that is: width is mostly a “paragraph style” thing, while weight can often be a “character style” thing. 

Mark Simonson

If you look at pre-digital type specimen catalogs, the list of styles in a family are usually sorted by width, then by weight, even though weight comes first in the name. And then you also get oddities like Bold Condensed Italic, rather than Bold Italic Condensed. 

John Hudson

I think width before weight makes total sense, because I don’t think of width as a typographic style variance in the same way that bold weight and italic slant are. Those are styles commonly applied to type of otherwise coordinated size and proportion to affect typographic articulation of text. So it makes sense to me that weight is defined as a stylistic variance of a proportional subfamily.

Nick Shinn

Perhaps it’s a preference for dactyl over anapest.
In other words, “Bold Condensed” may not be the most logical configuration, but it rolls off the tongue more comfortably than “Condensed Bold.”

That may not be the case in languages other than English.

Thomas Phinney

Note that the desirable order of elements in the name is not necessarily the same as the desirable sort order for the styles.

Ray Larabie

@Thomas Phinney Do you think the move to width/weight in digital fonts initially occurred because of the technical limitations? Was it even possible to have a Fontname Bold Condensed Italic in the early days? Wouldn't there have been a separate Fontname Condensed family with R,I,B,BI?

John Hudson

Wouldn't there have been a separate Fontname Condensed family with R,I,B,BI?

Yes. TT/OT name table IDs 1, 2 and 6 effectively require naming with weight and italic styles as the final element.

In theory, the STAT table introduced with OTvar could make naming a lot more flexible, and even allow users to decide how they want algorithmically generated names to be constructed in local font menus.

Thomas Phinney

Ray Larabie said:

@Thomas Phinney Do you think the move to width/weight in digital fonts initially occurred because of the technical limitations? Was it even possible to have a Fontname Bold Condensed Italic in the early days? Wouldn't there have been a separate Fontname Condensed family with R,I,B,BI?

There are several separate pieces of this.

The heuristics, algorithms and naming choices I was talking about were all in the context of a loosening of technical restrictions that we were plotting around 1998 or 1999, for Adobe CoolType apps, with more sophisticated font handling, and for OpenType fonts with their fancy/extended name fields. So we were plotting out exactly how we wanted to handle things. Users would have started noticing this around the year 2000+ as the functionality landed in Adobe apps and Adobe’s OpenType fonts started to appear. So yes, we had Fontname Bold Condensed Italic even then.

And before that, we did at least for Adobe Type Reunion customers—a utility that did similar things on Mac at least. Sairus and I were mapping out what to do moving forward, and trying to think through all the scenarios at once.

BTW, I know that I usually hog all the glory around this stuff, but as I recall, doing all this was initially driven by Sairus Patel. IIRC, he came to David Lemon asking for help and David suggested I might be the best person to sit down with Sairus and sort it out. It was just that the same decisions being made for CoolType and Adobe font menus then informed how we handled the naming for Adobe OpenType fonts, both for new fonts, and for converting the entire Adobe Type Library.

Now, OpenType fonts also supported legacy-style family groupings like Fontname Condensed, with R I B BI styles, for Windows in particular. And we had to track both kinds of data, and it got used in other apps, both less savvy or older Adobe apps, and third party apps. We also used that Windows info to help us handle “style linking,” so we knew what font to switch to if you used a keyboard shortcut for italic or bold.

Peter Constable

I'll mention that Windows GDI APIs were designed to support multiple weights within a single family, not just regular and bold. It's still possible to create a family with multiple (> 2) weights all having the same family name (name ID 1), and if an app called the GDI APIs with different lfWeight values it could access the different weights in the family.  However, early on in Windows history there weren't many families available with more than R I B BI faces, and applications introduced "B" and "I" icons and corresponding keyboard shortcuts effectively assuming that families would only have R I B BI members.

When WPF was first developed, CSS2 was also being developed, and the drafts for that included font-weight, font-stretch and font-style properties, so WPF assumed a family model in which a family could have weight, width and italic/oblique faces. When DWrite was first developed a few years later, it assumed the same WSS family model.

With the introduction of variable fonts in OpenType 1.8, that really made it no longer practical to have APIs impose a limitation on the axes of design variation that could exist within a family—the notion of family really needed to be left to whatever designers chose to treat as a family. So, new DWrite APIs were added to allow for unconstrained typographic families. (The older WSS-based APIs still exist as well.) At the same time, we new there would be existing applications using older assumptions, which is why the STAT table was defined: it makes it possible to map any face into an RIBBI-compatible descriptor based on name IDs 1/2, or a WSS-compatible descriptor using name IDs 21/22.

Of course, how font options are exposed to authors is still determined by how application UI is designed. For variable fonts with multiple axes and a lot of named instances, assuming the RIBBI family model will mean that a lot of related subfamilies could be listed in a font dropdown. E.g.,



Microsoft Office web apps have a newer font-picker UI that organizes at least weight and width variations into a single family:



Of course, this brings us back to what's been discussed already in this topic: should sub-family organization be first by width then by weight, or by weight then by width?

Note that, in the Office UI, the list of faces is sorted by width then by weight, even though the face names are arranged <weight> <width>. For comparison, see how the same UI lists the faces for Verdana Pro, which has face names arranged <width> <weight>:



The list is still sorted by width then by weight (then by style), just as for Bahnschrift.

John Hudson

Note re. Peter’s post: WWS (weight, width and slant), not WSS.

John Hudson

The list is still sorted by width then by weight

Is is sorted by width, or just grouped by width? i.e. if Bahnschrift or Verdana Pro included Extended as well as Condensed designs, how would the style list be ordered? It looks like the Normal width might always be ordered first, rather than, say, sorted from narrowest to widest.

Thomas Phinney

> should sub-family organization be first by width then by weight

Organization should be first by width, then by weight, then by slope

However, the order of particles within the name can be a separate thing. I for one would rather see “Bold Condensed Italic” than “Condensed Bold Italic” for the style name. Partly this is for crazy tradition reasons (this is the “normal” name ordering in my opinion), but also when I try to scan the menu list, all the Condensed are grouped together anyway, so listing “Condensed” first doesn’t help me much. I find it takes more time/effort to figure out the weights within that group when weight isn’t the first thing in the style list.

I am not thinking there is a single answer that will make everyone happy, of course. And that ordering of particles within the name is presumably based on the font data itself, not something the app is controlling or overriding, yes?

If it WAS controlled by the app, I would think a user preference for this would be a Good Thing.

John Hudson

I for one would rather see “Bold Condensed Italic” than “Condensed Bold Italic” for the style name.

I suspect the phenomenon of adjective order—something observed across languages—is at play here. While the distinction between ‘Bold Condensed Italic’ and ‘Condensed Bold Italic’ is less jarring than the classic example of ‘big green car’ vs ‘green big car’, I think it similarly reflects how we commonly think about adjectival qualities. Boldness feels like a secondary quality of something that is narrow or wide, not vice versa.