Irrational rationale for com.google.fonts/check/usweightclass
See original GitHub issueObserved behaviour
>> com.google.fonts/check/usweightclass
Checking OS/2 usWeightClass.
with ./Fonts/vf/Petrona[wgth].ttf
* FAIL: OS/2 usWeightClass expected value for 'Regular' is 400 but this font has 82.
GlyphsApp users should set a Custom Parameter for 'Axis Location' in each master to ensure that the information is accurately built into variable fonts. [code: bad-value]
Result: FAIL
Expected behaviour
Apart from the usWeightClass
issue already described here and here, I don’t see how adding a Axis Location
custom parameter would change anything.
It feels like the rationale text is misleading here. As mentioned in the other issue referenced above, GlyphsApp users should rather set a weightClass
custom parameter on the instances, or better yet, fontmake
can set these values itself according to the weights set in the instances.
Resources and exact process needed to replicate
This is the VF: Petrona-ROMAN-MASTER-NEW-W.glyphs
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Rational irrationality - Wikipedia
The concept known as rational irrationality was popularized by economist Bryan Caplan in 2001 to reconcile the widespread existence of irrational behavior ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
A note for @felipesanches on the suggested fix: I helped get weight locations working in Nunito By setting axis location custom parameters in instances (and not masters). Setting this in masters resulted in avar values only being present for master weight values (200,800,1000), and as a result, the other instance values were a bit off (Regular was something like 432.34375, etc).
I’m not 100% sure that it also set weightClass values correctly, though – I assume so, but I’d have to check specifically.
It shouldn’t be, at least not in a TTF.
https://github.com/googlefonts/fontbakery/issues/2644 is an issue to correct this, but ultimately it looks like it’s an issue of how the name parser isn’t yet built to parse style names that aren’t just weight names (so, the width descriptor is messing with it).
Interestingly, apparently old versions of windows auto-bolded CFF/OTF fonts with a weight of <= 249, and I guess that’s where the “250” comes from. https://typedrawers.com/discussion/2477/numeral-values-of-weights