Fontbakery: ERROR Failed with KeyError: 'slnt'

[bghryct]

Observed Behavior

After making jost[slnt,wght].ttf in with fontmake as below

fontmake -g source/jost.glyphs -o variable --round-instances -a --output-path source/vf/jost[slnt,wght].ttf

When I put output jost[slnt,wght].ttf through fontbakery I get the following error

💔 ERROR: Check variable font instances have correct coordinate values
com.google.fonts/check/varfontinstancecoordinates

💔 ERROR Failed with KeyError: 'slnt'

Expected Behavior

Should not have an issue with 'slnt"

Others have experienced this as well

@thundernixon had a similar error with his 'mono' axis

 >> com.google.fonts/check/varfont_instance_coordinates
   Check variable font instances have correct coordinate values
   with font_betas/recursive-MONO_CASL_wght_slnt_ital--full_gsub--2019_11_19-19_44.ttf

   * ERROR: Failed with KeyError: 'MONO'
          File "/Users/stephennixon/type-repos/recursive/venv/lib/python3.7/site-packages/fontbakery/checkrunner.py", line 344, in
_exec_check
            for sub_result in result:  # Might raise.
          File "/Users/stephennixon/type-repos/recursive/venv/lib/python3.7/site-packages/fontbakery/profiles/googlefonts.py", lin
e 3974, in com_google_fonts_check_varfont_instance_coordinates
            if instance.coordinates[axis] != expected_instance.coordinates[axis]:

[thundernixon]

As far as I can tell, it seems that the problem is with fontbakery's instance_parse() function, which appears to set up expected instance axis values based on the instance name ... BUT only includes values for opsz, wght, and wdth.

https://github.com/googlefonts/fontbakery/blob/d78810411152f449b1d302f7401d4e3e2c2bd775/Lib/fontbakery/parse.py#L183-L194

We (probably) can't really predict the values of other axes, like slnt or MONO. So basically, I think we just need something that only checks the name based on the axes that are in the instance parse, but doesn't try to check for axes that aren't.

[m4rc1e]

@thundernixon is correct. @felipesanches perhaps this check should produce a WARN if a VF contains and axis which we don't know how to name yet?

[kosbarts]

I am getting the same ERROR message in Commissioner. Is there a fix coming up soon?

[weiweihuanghuang]

I'm getting this issue even on a wdth axis:

for example:

* 🔥 **FAIL** Instance "Extended Thin" wdth value is "125.0". It should be "100.0" [code: bad-coordinate]
* 🔥 **FAIL** Instance "Extended ExtraLight" wdth value is "125.0". It should be "100.0" [code: bad-coordinate]

[arialcrime]

Getting similar messages with Fraunces. Waiting for a fix to continue work on it.

[m4rc1e]

@weiweihuanghuang "Extended" isn't a recognised width. I'm going to work on these coordinate checks now. Apologies for the confusion it's causing.

[m4rc1e]

I'm partway through refactoring these checks. I've used @arialcrime's family as a reference.

The updated VF instance checks will do the following:

• Submit a warn if instance names are not fully parsable. It will also output the unparsable tokens.
• Submit a fail if instance coordinates are incorrect for known axes
• Submit a fail if the fvar contains known axes and they're not mentioned in instance names.
• Submit a fail if instance names is incorrectly ordered
• If any fail or warn occurs, output a hint to study the GF spec (wip)

    * WARN: Instance "144 G100 Thin": contains the following unparsable tokens "['144', 'G100']"
    * FAIL: Instance "144 G100 Thin": does not contain "opsz" token.
    * WARN: Instance "144 G100 Light": contains the following unparsable tokens "['144', 'G100']"
    * FAIL: Instance "144 G100 Light": does not contain "opsz" token.
    * WARN: Instance "144 G100 Regular": contains the following unparsable tokens "['144', 'G100']"
    * FAIL: Instance "144 G100 Regular": does not contain "opsz" token.
    ...
    * WARN: Instances may be incorrect. See our spec for further info ...

[felipesanches]

Thanks a lot, @m4rc1e
This sounds like a great improvement!

[weiweihuanghuang]

Thanks Marc!

[arialcrime]

Cool, that looks promising. Do you have a time-frame until when this spec will be complete and approved by @davelab6?

[m4rc1e]

@arialcrime It may take a while I'm afraid. I have around 5 tasks of similar importance that are on going. In the meantime, please name your instances as 144pt Thin G100 etc.

[m4rc1e]

Ok, I've had more time to work on this. Here's how it's looking for a bunch of new VF families that we're going to release soon:

Fraunces:

    * WARN: Instance "9 G0 Thin Italic": contains the following unparsable tokens "['9', 'G0']"
    * WARN: Instance "9 G0 Thin Italic": Cannot determine instance name due to unparsable tokens
    ...
    Instances may be incorrect. See our spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb#instances

Inconsolata:

    * FAIL: Instance "UltraCondensed": Name is missing the following tokens [wght]
    * FAIL: Instance "UltraCondensed": Name should be "UltraCondensed Regular"
    ...
    Instances may be incorrect. See our spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb#instances

Work Sans:

    * PASS: Instances are correct

It's pretty much impossible to anticipate how devs are going to name their instances hence if the check either fails or warns, a recommendation to read our spec comes up