For a font with wght and opsz axes, if a vendor chooses to register all weights for "Text" and for "Display", but intentionally does not want to provide mid-opsz_, normal_ "Regular"/"Bold" instances, this check always fails with:
Observed behaviour
"Regular" instance not present.
And from the rationale in the check:
According to the Open-Type spec's registered design-variation tags,instances in a variable font should have certain prescribed values.
If a variable font has a 'wght' (Weight) axis, the valid coordinate range is 1-1000.
If a variable font has a 'wdth' (Width) axis, the valid numeric range is strictly greater than zero.
If a variable font has a 'slnt' (Slant) axis, then the coordinate of its 'Regular' instance is required to be 0.
If a variable font has a 'ital' (Slant) axis, then the coordinate of its 'Regular' instance is required to be 0.
Expected behaviour
The font I describe above does fit within what should be confirmed, but the rather narrow definition of requiring plain "Regular" and "Bold" instances makes the check output a warning, regardless. This gives the impression that FB recommends explicitly having such-named instances, as opposed to what the check rational actually argues: enforcing the sanity check of axis values.
|
upright = get_instance_axis_value(ttFont, "Regular", "wght") |
just seems too naive
in this context. For this check, it would make a lot more sense to look at axis defaults, crosscheck against instances sitting on those, and judge the presence or lack thereof.
Furthermore, the result of the "Regular" instance not present. branch of is a FAIL verdict, but this is due to the condition being to lax.
If indeed there is an argument (usability, maybe? providing defaults?) for the plain "normal" instances, that should be split into a separate check.
For a font with
wghtandopszaxes, if a vendor chooses to register all weights for "Text" and for "Display", but intentionally does not want to provide mid-opsz_, normal_ "Regular"/"Bold" instances, this check always fails with:Observed behaviour
And from the rationale in the check:
Expected behaviour
The font I describe above does fit within what should be confirmed, but the rather narrow definition of requiring plain "Regular" and "Bold" instances makes the check output a warning, regardless. This gives the impression that FB recommends explicitly having such-named instances, as opposed to what the check rational actually argues: enforcing the sanity check of axis values.
fontbakery/Lib/fontbakery/checks/conditions.py
Line 138 in 758c9a5
Furthermore, the result of the
"Regular" instance not present.branch of is aFAILverdict, but this is due to the condition being to lax.If indeed there is an argument (usability, maybe? providing defaults?) for the plain "normal" instances, that should be split into a separate check.