The Evolution of Font Weight Terminology: A Historical Question

Ray Larabie

I've been reorganizing the weight hierarchy in my older typefaces and noticed something puzzling: the historical placement of weight names, particularly “Book,” seems different from modern conventions. This got me wondering about how our current weight naming system evolved.

My experience with digital font weights began in 2000 when I started using FontLab.


(image from the menu in FontLab Studio 5)

Back then, I organized my weights below Regular in a way that now seems outdated: I placed Book as the heaviest of the light weights, followed by Light, then Extra-Light, and finally Ultra-Light at the thinnest end of the spectrum.

Today, I understand this hierarchy was incorrect. What I once called Book is now typically labeled as Light, my old Light weight has become Extra-Light, what was Extra-Light is now known as Thin, and my Ultra-Light weight is now Hairline. This new organization makes more sense for menu sorting, but the PANOSE weight settings still reflect the older, more confusing system. But it's even worse, with Thin hanging out between Book and Light. And why Extra and Very? Pick one!


(image from the menu in FontLab Studio 5)

What I'd like to understand is how this confusing weight hierarchy developed in the first place. Was there a logical rationale behind the original weight ordering? It's particularly surprising that font design applications would implement a non-standard weight hierarchy, given that their developers presumably had access to typographic expertise. While I can understand potential oversights in the PANOSE table development as they were likely software engineers with less typographical background, the broader adoption of this system in professional type design software is more puzzling.

Does anyone have historical insight into how these weight naming conventions evolved?

Did other type design applications follow similar hierarchies?

Are we finally all in sync?

Thomas Phinney

The TrueType/OpenType specification and its usWeightClass field started driving this in the  90s. https://learn.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass

So what FontLab offers as defaults is taken straight from there, with a couple of additions that are taken as synonyms for existing values.

John Hudson

I recall ‘Book’ weight being discussed previously on TypeDrawers. There is no technical specification for this term. It isn’t included in the named usWeightClass values of the OS/2 table specification, and hence does not have a standard location on the OTvar wght axis scale.


I think Book weight has to be understood as ‘the weight suitable for paragraph text in book typography’, and always has to be defined relative to the nominal Regular weight of a particular typeface. The position of Book on the weight scale is going to depend on the nature of the design and the weight of the Regular. If the Regular weight is suitable for book typography, there is no need to define a Book weight. If the Regular weight is too heavy for book typography, then a lighter Book weight can be defined. If—as I find to be more often the case, especially in older digital font families—the Regular weight is too light for book typography, then a heavier Book weight can be defined.

[In the new version of Ross’ Euphemia family, I decided to name the numeric Medium (500) instance ‘Book’ because it is the appropriate weight of the design for book typography.]

Nick Shinn

A short essay I wrote about “book” weight, at Quora (before that site lost the plot).

John Butler

Tangential to this: many Scangraphic designs come in both “Book” and “Headline” versions, typically suffixed SB and SH respectively, where the same exact outlines have different sidebearings and kerning. I’d not be surprised if other foundries around that time had done something similar.

Kent Lew

Ha, I don’t think I ever knew what the SB and SH stood for.

PabloImpallari

Similar to what John said about the specifications for weight, can also be considered for width names

The initial Encode Sans release used "compressed" "narrow" and "wide" names, but we ended up renaming those to match the usWidthClass too.

John Savard

And here I thought that the "Book" version of a typeface was simply another closely related typeface. Thus, Aldus could have been called Palatino Book, as indeed I once read that Hermann Zapf himself intended.