com.google.fonts/check/STAT/gf_axisregistry: why does it complain about entries not in the registry?

[madig]

A certain font has a ROND and snlt axis, and in the STAT table I cannot name any locations other than the default, because the check will complain about them. Why? Removing the extra entries then may trip up com.adobe.fonts/check/stat_has_axis_value_tables when an instance uses a removed entry...

Shouldn't it be limited to checking the defaults it knows about?

[felipesanches]

@madig, I'll take a look at this now. Please let me know (just to be sure) which version of fontbakery you are using. And also where can I get a sample font binary of that "certain font" that I can use to replicate the issue locally on my computer. If you do not want to mention the font name in public, you can tell me that over email at [email protected]

[felipesanches]

I'm not sure.

The axisregistry documentation has this:

fallback

Instance positions along the axis, such as wght 100,200,300,400,500,600,700,800,900.
A cross-product of fallback positions along all supported axes is created to support legacy browsers that lack variable font support. For axes with CSS3 properties (such as [font-weight](https://drafts.csswg.org/css-fonts-3/#font-weight-prop)), the positions accessible to CSS3 should be specified. For axes lacking CSS3 properties a legacy browser is limited to a single position and that position must be at a fallback.
In case an axis doesn't include predefined positions, it is mandatory to define at least one fallback position. It should be called Default and its value should correspond to the default_value position of the axis.

fallback_only
Describes whether to only use fallback values when presenting to users in the UI. Currently, default to true, for continuous range axes should be set to false.

The slnt axis only has "Default" on the axisregistry and it also has falback_only=false. I am not sure but, perhaps the fontbakery check should only enforce fallback names when falback_only is true?

If that's the case, then we'll need to open an issue on fontbakery to change the behaviour of com.google.fonts/check/STAT/gf_axisregistry

I need someone else to review this. Maybe @m4rc1e knows better?

[felipesanches]

Also, in cases like this, one can read the conversation that led to the proposal of implementation of a given check. In this case, it was proposed in Aug 24, 2020 by @m4rc1e at #3022

note: this link is available in the proposal metadata field of the check, as seen here:
https://github.com/googlefonts/fontbakery/blob/b734f96017b82d41fb0014472e92192036d8eb8d/Lib/fontbakery/profiles/googlefonts.py#L5913