Is it legitimate for different font weights to have the same usWeightClass values?

Rick Davies

Dear font experts,

I hope it's OK to post this question here. If not, if you are able to suggest a better
alternative it would be great.

It appears that the 'Exo' font from Google fonts has:

Exo-ExtraLight.ttf:    <usWeightClass value="250"/>
Exo-ExtraLightItalic.ttf:    <usWeightClass value="250"/>
Exo-Thin.ttf:    <usWeightClass value="250"/>
Exo-ThinItalic.ttf:    <usWeightClass value="250"/>

So I'm wondering--are duplicate usWeightClass values for different font weights:

        * Permitted?
        * Permitted, but non-standard?
        * Permitted, but completely abberant?
        * Permitted, but likely an inadvertency on the part of the font creator?
        * Commonplace?

AFAICS, as someone at least 100 km from being a font expert, I'm guessing the above
usWeightClass scheme is not supported in CSS or by browsers? (This is not actually my
context. It's more to do with the font file selection process for font families and
preferred font families. A miasma.)

Many thanks for any advice or comments.

With appreciation for a great forum,

Rick

André G. Isaak

It will likely cause the styles to sort incorrectly in menus, but the fonts will still be usable. It was likely done inadvertently.

K Pease

I recall some advice here not to set numerical weights below 250. I think it's because an operating system clumsily auto-bolds anything designated lighter, with the presumption that anything so light will need more weight to be seen clearly on a screen. This probably informs the Exo example. I don't know why one would not use e.g. "251" for the sake of sorting, but for all I know there's a problem with that too.

c.g.

I just installed Exo on Windows 10 and all 18 styles are recognised. But it doesn't seem a good idea to me.

Exo ExtraLight is named "Chiarissimo" by Windows (Italian language); Exo ExtraLight Italic is named "finissimo". Two different weight names.

Jens Kutilek

You need to test this in different applications, not only in the system fonts folder. I seem to recall that Word on Mac and Adobe XD and Windows don't play well when fonts other than one upright and one italic style per family share the same weight class. Some styles would be replaced by another when selected in the font menu.

c.g.

Jens Kutilek said:

You need to test this in different applications, not only in the system fonts folder. I seem to recall that Word on Mac and Adobe XD and Windows don't play well when fonts other than one upright and one italic style per family share the same weight class. Some styles would be replaced by another when selected in the font menu.

I agree. That's why I think it's not a good idea at all. If the system fonts folder doesn't recognise them correctly, probably the fonts won't play well in some application.

And if the family uses linked styles (same family name for bold and regular styles), user will be able to use only 2 of 4 styles.

Thomas Phinney

Having different weights with the same usWeightClass is not commonplace. I consider it a bug. It is an area I know a fair bit about.

BACKGROUND

Many old Windows GDI apps use the GDI API in a way that assumes the only legit weights are 400 and 700. This results in a smear bold effect for any weight below 250.

This was historically worked around by many font vendors, by not having any usWeightClass value below 250. If doing that, and having to deal with weights that “ought” to be 100 as well as 200, one reasonable option is to use 250 and 275, so as to have two distinct usWeightClass values. This is what my then-team at Adobe did in the oughties.

Whether there are enough apps around with the problems today that it is still worth trying to work around, I don’t know. And different people might reasonably have different answers to that question. CSS and OpenType specification purists will say not to work around desktop app bugs at all!

But I do say that folks working around it ought to still keep the WeightClass values distinct. It is just a bug, IMO.

Marc Foley

I reckon you may be looking at the Exo variable font. If I inspect the downloadable static fonts, they all have different usWeightClasses. They are all the same for the VF because it's actually a single font.

https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview

Can you provide a link to the files please?

Erwin Denissen

Marc Foley said:

I reckon you may be looking at the Exo variable font. If I inspect the downloadable static fonts, they all have different usWeightClasses.

I wonder how you inspect the files, as with the static fonts I downloaded both Extra Light and Thin have their weight set to 250.

Simon Cozens

simon@Simons-iMac ~/others-repos/fonts *$ git remote -v
origin	https://github.com/google/fonts/ (fetch)
origin	https://github.com/google/fonts/ (push)

simon@Simons-iMac ~/others-repos/fonts *$ ttx -o - -t "OS/2" ofl/exo/static/Exo-Thin.ttf 2>/dev/null | grep usWeightClass
    <usWeightClass value="100"/>

simon@Simons-iMac ~/others-repos/fonts *$ ttx -o - -t "OS/2" ofl/exo/static/Exo-ExtraLight.ttf 2>/dev/null | grep usWeightClass
    <usWeightClass value="200"/>    

Erwin Denissen

I use Firefox to download the fonts from Google (I am on Windows and don't use ttx), and those files seem different.

Peter Constable

Marc Foley said:

I reckon you may be looking at the Exo variable font. If I inspect the downloadable static fonts, they all have different usWeightClasses. They are all the same for the VF because it's actually a single font.

https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview

One font file, one OS/2 table, so one usWeightClass value in the distributed data. But if the variable font has a wght axis, then the instance weight class is determined by the setting of the wght axis, not the static usWeightClass value.

"For non-default instances of a variable font, the 'wght' axis value can be used as the OS/2.usWeightClass value for the instance."

https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wght

Mike Wenzloff

Erwin Denissen said:

I use Firefox to download the fonts from Google (I am on Windows and don't use ttx), and those files seem different.

Google Fonts Github repository is using the 1.0 version while the Google fonts website is serving the 2.0 version.

The 1.0 version has the weights correct from a quick look while the 2.0 version is incorrect.

Rick Davies

Thank you all, André G., K Pease, Cesare G., Jens Kutilek, and Thomas Phinney for your helpful and illuminating comments. And also to the  other later posters.

As just one example Cesare wrote:

    > Exo ExtraLight is named "Chiarissimo" by Windows (Italian language); Exo ExtraLight Italic is named "finissimo".

I had thought this naming would come from the font <namerecord> langID value, triggered by the host system language locale. But the Exo font only has langID="0x409", i.e. US English on Windows. So that display naming must be a Windows thing ...

After reading your comments and doing a bit more research (see below), my answer to my question is duplicate usWeightClass values within a typographical font family are:

        * Permitted, but likely an inadvertency on the part of the font creator.


FWIW The background to my question is an endeavor to derive an algorithm for font family names and weight variations. It's proving more complicated than I imagined. The only documentation I've found so far is:

    Font selection model used by Windows Presentation Foundation: description and guidelines.
    by Mikhail V. Leonov, David C. Brown, Dated 2006.
    Found at: https://www.noesisengine.com/bugs/file_download.php?file_id=1356&type=bug

So it's not a question about what a font designer/creator needs to do to ensure their font will work with all applications and on all platforms (nightmarishly complicated it seems) but how an application should treat what font designers/creators have done in say, the past 10 years, and are likely to do in the next ten years. For this reason it's a discussion that's maybe not appropriate to this forum. OTOH, there does not seem to be anywhere else: the OpenType list is great, but a little druidic for an outsider.

AFAIK none of the fonts I've been testing with are variable fonts. All were/are fonts downloaded from Google Fonts and found on my system.

Getting back to the original question, since my post I've come across the 'Fira Sans' OTF font family, downloaded from somewhere in 2015, with 16 different weights. *Five* (!) of these weights have

    usWeightClass="100"

i.e. 'Thin', 'Hair', 'Two', 'Four', 'Eight'.

Adobe InDesign CS6 manages to disambiguate them into a selection list 32 items long (including Italic variations), even listing the cryptic 'Ultra' (should be 'UltraHeavy'?) at the end. That's based on the 'Ultra' usWeightClass. The fonts with duplicated weight classes are sorted alphabetically. The algorithm Adobe uses to do this is presumably secret sauce.

Another puzzling wrinkle: downloading 'Fira Sans' from

    https://fonts.google.com/specimen/Fira+Sans

a few days ago, the font has become a TTF and the following weights have disappeared:

    Eight, Four, Two, Hair, Ultra, UltraLight and Book.

*And* the usWeightClass for 'Thin' has changed from 100 to 250. There are no longer any duplicated usWeightClass values.

Reading the runes of the OpenType specification it's hard to see the need for the weight class change for 'Thin' from 100 to 250.

A cursory check of 1200 font files on a Windows system showed:

    1000 TTFs of which 12 contained usWeightClass = 100
     200 OTFs of which 0 contained usWeightClass = 100

Ideally a font d/l site could do a more extensive analysis.

Conclusion: an application cannot assume that members of font family should have no duplicated usWeightClass values (apart from for Italic variations). Which agrees, sort of, with all the comments kindly posted above.

Thanks again,

Rick

PS.
As an outsider, on the font deciphering side rather than on the font creation side, Pedro Mascarenhas's idea for a recommended list of font weight numbers and associated names seems attractive, regardless of one font's 'Thin' possibly being heavier than another font's 'Black'.

    https://typedrawers.com/discussion/3955/what-is-the-proper-name-to-give-to-each-weight-tyms-weights-tw-thesis

at least for Latin script or alphabetic fonts. At anyrate it would make life easier for developers wanting to create a selection mechanism for typographic font families.

PPS.
Traipsing around this site a bit more since, I see people talking about font families with 40+ styles, For now I'm closing my eyes to that (-:. And different opinions as to how such choices should be presented to benighted end-users. Maybe an area for standardization?

Thomas Phinney

“ my answer to my question is duplicate usWeightClass values within a typographical font family are:

        * Permitted, but likely an inadvertency on the part of the font creator.”

If the context is that the styles in question are legitimately the same weight, but different styles, then of course it is permitted. That is, Vogon ExtraLight and Vogon ExtraLight Italic should have the same usWeightClass.

If you mean different weights? If the spec does not explicitly disallow it, it certainly should. Developers/designers who assign the same usWeightClass to different weights in the same family are just asking for trouble, and I would be surprised if one did not find some contexts in which the fonts misbehaved.

“Reading the runes of the OpenType specification it's hard to see the need for the weight class change for 'Thin' from 100 to 250.”

I explained why this was done (in painful detail!) in an earlier post in this thread. Ernie March and I did a lot of testing and investigation on the issue, back around 1999-2000 or thereabouts. (The only thing I left out, above, was some complexities around style linking between unusual weightclass values.)

Jens Kutilek

If you have the need to use identical weightClass values for styles that don’t differ in widthClass or italicness (bit 0 of OS/2.fsSelection), you should unset bit 8 of the OS/2.fsSelection table ("WWS") and also add fallback name IDs 21 and 22.

For example, the "Small Caps" style does not fit in the WWS scheme:

ID16    ID17               Weight  Width  Italic  ID21       ID22
MyFont  Regular Italic     400     5      true    MyFont     Regular Italic
MyFont  Regular SC Italic  400     5      true    MyFont SC  Regular Italic

This way, apps that require WWS compatibility will list a separate "MyFont SC" family.

Other apps, e.g. InDesign, will group all styles under the "MyFont" family.

This is described in the OpenType spec for the fsSelection field.

c.g.

Thomas Phinney said:

If the context is that the styles in question are legitimately the same weight, but different styles, then of course it is permitted. That is, Vogon ExtraLight and Vogon ExtraLight Italic should have the same usWeightClass.

Definitely. Few years ago I purchased a some cuts of a family from a well known foundry, and noticed that the italics had weightClass incremented by 50 compared to the uprights (Regular: 400, Regular Italic: 450). Word wasn't able to handle this and used fake italics instead of the real ones.

Thomas Phinney said:

(The only thing I left out, above, was some complexities around style linking between unusual weightclass values.)

Would be very interesting to read, if you have time.

Rick Davies said:

FWIW The background to my question is an endeavor to derive an algorithm for font family names and weight variations. It's proving more complicated than I imagined.

Why? Maybe there's something I don't know, but I see no reason for it.

Thomas Phinney

Cesare G. said:

Thomas Phinney said:

(The only thing I left out, above, was some complexities around style linking between unusual weightclass values.)

Would be very interesting to read, if you have time.

I think it is more a question of whether YOU have time. Here is the Adobe documentation on the topic: http://adobe-type-tools.github.io/afdko/WinWeights.html

 I remade a table that used to exist, which shows the link issues visually: