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
0
Comments
Exo ExtraLight is named "Chiarissimo" by Windows (Italian language); Exo ExtraLight Italic is named "finissimo". Two different weight names.
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.
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.
https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview
Can you provide a link to the files please?
"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
The 1.0 version has the weights correct from a quick look while the 2.0 version is incorrect.
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?
* 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.)
For example, the "Small Caps" style does not fit in the WWS scheme: 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.
Would be very interesting to read, if you have time.
Rick Davies said: Why? Maybe there's something I don't know, but I see no reason for it.
I remade a table that used to exist, which shows the link issues visually: