Fontbakery: FAIL: Check variable font instances have correct names

Created on 20 Jan 2020  路  13Comments  路  Source: googlefonts/fontbakery

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

Support
Source
picture kosbarts

Most helpful comment

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

picture kosbarts on 20 Jan 2020
👍2

All 13 comments

fontbakery inference of familyname/stylename is based on splitting on the dash character. That's why it thinks the style is "Flair Thin" instead of "Thin"

felipesanches picture felipesanches on 20 Jan 2020

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

felipesanches picture felipesanches on 20 Jan 2020
👎1

Hi @felipesanches and thanks for the answer, but I am not quite sure what it is you are suggesting.

The variable font has 18*3=54 instances. Yet it has one family name.

Should I split it in 3 Variable fonts so that the naming is accepted?
Do you have an example of what you are talking about?

kosbarts picture kosbarts on 20 Jan 2020

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

felipesanches picture felipesanches on 20 Jan 2020
👎1

@davelab6 suggested to look into Recursive for a similar multi-axes instance family. I ran it through fontbakery and it reports the same FAIL.

kosbarts picture kosbarts on 20 Jan 2020

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

kosbarts picture kosbarts on 20 Jan 2020
👍2

@thundernixon, can you help us here?

felipesanches picture felipesanches on 20 Jan 2020

Having the same problem with width axis

weiweihuanghuang picture weiweihuanghuang on 13 Feb 2020

This is also (still) hampering work on Fraunces.

From what I can gather (and what @m4rc1e pointed out here), the problem seems to be the instance parser that is not able to deal with anything that is not width, weight, and italic.

arialcrime picture arialcrime on 13 Feb 2020

Sorry to have missed this issue for so long. Yes, my theory is that a variable font project should have a single, primary variable font if it鈥檚 possible to, in order to deliver maximum savings & flexibility to end users. Some projects would have separate variable fonts that aren't compatible, like many type families that have one roman VF and one italic VF.

In Recursive, the static fonts are given four separate families names each with 16 instances (8 weights + italics), to work easily in software like Keynote, Figma, InDesign, etc:

  • Recursive Mono Casual Static
  • Recursive Mono Linear Static
  • Recursive Sans Casual Static
  • Recursive Sans Linear Static

However, the variable font family has 64 total instances, and these have names like Mono Casual Bold Italic, etc.

This separation of families also makes it easier to install all 5 families (4 static, 1 variable) but keep them separately available in font menus.

I can鈥檛 dedicate time to fixing this issue in the immediate future, as I need to work through open priorities in Recursive. For now, I suggest just making Fraunces work as well as possible in as many places as possible, and trusting that this issue will be resolved eventually.

thundernixon picture thundernixon on 23 Apr 2020

Fontbakery's name parser was updated a while ago to accept non-registered axes. For Commisioner, Fontbakery now produces:

* WARN: Instance "Flair Thin": contains the following unparsable tokens "['Flair']"
    * WARN: Instance "Flair Thin": cannot determine instance name due to unparsable tokens
    * WARN: Instance "Flair ExtraLight": contains the following unparsable tokens "['Flair']"
...
    * WARN: Check has either failed or produced a warning. See our wip spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb

It's no longer a fail but a warn.

I still don't know if non-registered axis names should appear before or after registered axis? e.g

Before:
Flair ExtraLight Italic

After:
ExtraLight Italic Flair

For filenames we ask for non-registered to appear first.

@davelab6 ^

If we decide to have non-registered to appear first, then Commisioner's instance names are correct.

m4rc1e picture m4rc1e on 23 Apr 2020

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.

thundernixon picture thundernixon on 24 Apr 2020
👍1

Related discussion in https://github.com/google/fonts/issues/2702

davelab6 picture davelab6 on 28 Jan 2021
Was this page helpful?
0 / 5 - 0 ratings

Related issues

felipesanches picture felipesanches  路  5Comments
chrissimpkins picture chrissimpkins  路  6Comments
felipesanches picture felipesanches  路  6Comments
madig picture madig  路  8Comments
graphicore picture graphicore  路  7Comments