Add VF check to ensure os/2 weightClass is same as default wght axis position

[m4rc1e]

The OS/2 weightClass should be the same as the default wght axis position.

google/fonts#1857

[m4rc1e]

From the spec.

A variable font has a default instance, with axis parameter values set to the defaults defined for each axis in the 'fvar' table. Several tables in the font provide default values for many different data items — such as positions of glyph outline points in the 'glyf' table, or a font-wide ascender distance in the OS/2 table. The default instance of a font uses the default values for such items without any adjustments, and the variation-specific tables are not needed. If the variation-specific tables — 'fvar', 'gvar', MVAR, etc. — were to be removed from the font or ignored, the remaining data would comprise a complete font for the default instance.

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

I hope this makes things clearer.

[thundernixon]

There is a seeming conflict in these two checks:

🔥 FAIL: Variable font weight coordinates must be multiples of 100.
com.google.fonts/check/varfont_weight_instances
🔥 FAIL Found an variable font instance with 'wght'=250.0. This should instead be a multiple of 100.
🔥 FAIL Found an variable font instance with 'wght'=275.0. This should instead be a multiple of 100.

⚠️ WARN: Checking OS/2 usWeightClass.
com.google.fonts/check/020
⚠️ WARN {}:{} is OK on TTFs, but OTF files with those values will cause bluring on Windows. GlyphsApp users must set a Instance Custom Parameter for the Thin and ExtraLight styles to 250 and 275, so that if OTFs are exported then it will not blur on Windows.

...or potentially, we just need to be more specific about what custom parameter we tell people to set in Glyphs.

[thundernixon]

As a bit more context, if I set the weightClass custom param (there is no usWeightClass param) in the Glyphs source as suggested by FontBakery...

...then export via FontMake, it results in a font with:

<usWeightClass value="100"/>

...in the OS/2 table, and:

<AxisValueArray>
      <AxisValue index="0" Format="1">
        <AxisIndex value="0"/>
        <Flags value="0"/>
        <ValueNameID value="257"/>  <!-- Thin -->
        <Value value="250.0"/>
      </AxisValue>
      <AxisValue index="1" Format="1">
        <AxisIndex value="0"/>
        <Flags value="0"/>
        <ValueNameID value="258"/>  <!-- ExtraLight -->
        <Value value="275.0"/>
      </AxisValue>

...in STAT.

This is basically backwards of what I (think) fontbakery is asking me to do.

[thundernixon]

@m4rc1e when you say

The OS/2 weightClass should be the same as the default wght axis position.

I assume this means that if the default weight axis position is 100 (or 200) to work for CSS, then the OS/2 weight should also be 100 (or 200), rather than 250 (or 275). Correct?

If so, we should update check 112 for variable fonts.

[arialcrime]

Running into pretty much the same problem. Has there been any progress on how to deal with this contradiction in the meantime?

[m4rc1e]

@arialcrime have you assigned 250 to Thin and 275 to ExtraLight? if so, set them to 200 and 300.

[m4rc1e]

@felipesanches I reckon the requirement for 250 and 275 is dogma and should be investigated and dropped.

[felipesanches]

I wouldn't call it dogma because it had a clear rationale. I would potentially call it a deprecated practice, instead. Should we really deprecate it though?

[m4rc1e]

I don't see a rationale, https://github.com/googlefonts/fontbakery/blob/master/Lib/fontbakery/profiles/googlefonts.py#L800-L837 I just see dogma. No one has tested the otf blur assumption AFAIK.

[arialcrime]

@arialcrime have you assigned 250 to Thin and 275 to ExtraLight? if so, set them to 200 and 300.

Thanks Marc. Any particular reason why these values don’t follow the recommendation of the spec?

[m4rc1e]

We believe that Thin and ExtraLight should not be set to 100 and 200 for CFF fonts. We think they get blurred on certain versions of Windows. Whether it's true or not is up for debate since no one has tested it.

[m4rc1e]

I have asked for time next year to clean up the name checks. Hopefully I'll find time to solve these edgecases because they're infuriating.