fontbakery: FAIL: Check variable font instances have correct names

Observed behaviour

I am testing a variable font with four axes. There are combinations of the unregistered and registered axes in the instance naming, for obvious reasons, i.e. Commissioner-Thin, Commissioner-FlairThin, Commissioner-LoudThin, etc.

When fontbaking the vf, I get the following FAIL: `

🔥 FAIL: Check variable font instances have correct names

  • com.google.fonts/check/varfont_instance_names

  • 🔥 FAIL Instance name “Flair Thin” is incorrect. It should be “Thin” [code: bad-name]

  • 🔥 FAIL Instance name “Flair ExtraLight” is incorrect. It should be “ExtraLight” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Light” is incorrect. It should be “Light” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Regular” is incorrect. It should be “Regular” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Medium” is incorrect. It should be “Medium” [code: bad-name]

  • 🔥 FAIL Instance name “Flair SemiBold” is incorrect. It should be “SemiBold” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Bold” is incorrect. It should be “Bold” [code: bad-name]

  • 🔥 FAIL Instance name “Flair ExtraBold” is incorrect. It should be “ExtraBold” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Black” is incorrect. It should be “Black” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Thin Italic” is incorrect. It should be “Thin Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair ExtraLight Italic” is incorrect. It should be “ExtraLight Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Light Italic” is incorrect. It should be “Light Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Italic” is incorrect. It should be “Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Medium Italic” is incorrect. It should be “Medium Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair SemiBold Italic” is incorrect. It should be “SemiBold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Bold Italic” is incorrect. It should be “Bold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair ExtraBold Italic” is incorrect. It should be “ExtraBold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Flair Black Italic” is incorrect. It should be “Black Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Thin” is incorrect. It should be “Thin” [code: bad-name]

  • 🔥 FAIL Instance name “Loud ExtraLight” is incorrect. It should be “ExtraLight” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Light” is incorrect. It should be “Light” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Regular” is incorrect. It should be “Regular” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Medium” is incorrect. It should be “Medium” [code: bad-name]

  • 🔥 FAIL Instance name “Loud SemiBold” is incorrect. It should be “SemiBold” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Bold” is incorrect. It should be “Bold” [code: bad-name]

  • 🔥 FAIL Instance name “Loud ExtraBold” is incorrect. It should be “ExtraBold” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Black” is incorrect. It should be “Black” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Thin Italic” is incorrect. It should be “Thin Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud ExtraLight Italic” is incorrect. It should be “ExtraLight Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Light Italic” is incorrect. It should be “Light Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Italic” is incorrect. It should be “Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Medium Italic” is incorrect. It should be “Medium Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud SemiBold Italic” is incorrect. It should be “SemiBold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Bold Italic” is incorrect. It should be “Bold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud ExtraBold Italic” is incorrect. It should be “ExtraBold Italic” [code: bad-name]

  • 🔥 FAIL Instance name “Loud Black Italic” is incorrect. It should be “Black Italic” [code: bad-name]

  • 🔥 FAIL This will cause problems with some of the Google Fonts systems that look up fonts by their style names. This must be fixed! [code: bad-instance-names]`

Expected behaviour

Is there some clear guidelines for how instances in families with multiple axes should be named?

Resources and exact process needed to replicate

variable file bakery report source file

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 41 (10 by maintainers)

Most upvoted comments

Doesn’t splitting it into 3 families void the whole concept of it being a variable font?

+3
kosbarts on Jan 20, 2020

But I won’t change my fonts to follow this wght-only fvar limitation, it makes the free software user experience tangibly worse for users of my fonts, including myself. I’m being told to break my font for the users who care enough about software freedom to only use it and won’t do that.

@ctrlcctrlv, I suggest we could get together to collaborate on an issue on the Inkscape issue tracker in which we could plan how to improve the variable fonts support in Inkscape so that we can change the current scenario you described.

+2
felipesanches on Nov 8, 2022

if non-registered axis names should appear before or after registered axis

In the case of this family, it looks to me like “Flair” and “Loud” are sort of like subfamilies, and should therefore go before weight and italic names. In general, also, I think that would tend to hold true.

However, it sounds like you might be seeking out a rule here, in which case I would be cautious about establishing any hard rules. It seems unlikely that every non-registered axis descriptor should necessarily be named before registered axis descriptor. I might be making this up, but I think that names have their current order as a way of describing font attributes in the way that people commonly see their order on the “decision tree” a designer might go through in selecting the correct style. So, presumably, someone could come up with a non-registered axis that would change names after the registered names.

In the example of Recursive, I don’t but could have instances like “mono casual bold oblique,” which would be like the “mono casual bold italic” but with the non-registered CRSV (cursive) axis turned to 0. So, this would affect the style name following registered descriptors. Presumably, other families might come up with other non-registered axes that would influence registered axes in ways that would be further down in the decision tree for the end user.

+2
thundernixon on Apr 24, 2020

That sounds confusing for all users but I see no other resolution as I clearly cannot accept Scenario 1 and you clearly won’t accept Scenario 2.

The good solution is to fix any broken free software (such as the current state of variable fonts in Inkscape)

+1
felipesanches on Nov 8, 2022

Is this really a good check?

Yes, given its scoped to the GF profile - although it IS poorly worded.

In theory, the wording can be quickly improved - but it requires someone who has a deeper understanding of what The Right Thing To Do is (which is probably only me, alas, since it requires knowledge of the gf product, and gf axis registry), and #2820 and #2824 were logged to do this, but haven’t moved since…

There is also history in https://github.com/googlefonts/fontbakery/issues/2573 as well as #2702.

FontBakery can’t be right here—can it?

It is right, and the smallest change I can see to make it clearer would be to change the strings from

> Check variable font instances have correct names (com.google.fonts/check/varfont_instance_names)
Check variable font named-style instances have correct names in fvar table (com.google.fonts/check/varfont_instance_names)
> Following instances are not supported:
Following fvar instances are not supported, because fvar is for legacy support, so only the 9 OS/2 named weights plus italic are a good idea to use in fvar:
+1
davelab6 on Nov 8, 2022

If we allowed any fvar instances, many fonts would have hundreds of em which makes it difficult to select an individual style.

How is that different from STAT, if app wants to list individual instances it would still be listing 100s of them, whether it got them from fvar or STAT.

+1
khaledhosny on Aug 13, 2022

yes, that’s right! A total of 3 families, each with 18 styles.

+1
felipesanches on Jan 20, 2020

well… Flair and Loud should be part of the family name. Styles should remain a selection of the 18 canonical stylenames.

+1
felipesanches on Jan 20, 2020
Read more comments on GitHub
← fontbakery: com.google.fonts/check/glyph_coverage: Please print all missing glyphs
fontbakery: fontbakery main executable not recognized in Powershell/cmd.exe because of missing .py suffix →