FontBakery requires specific instance names

[tphinney]

This looks like a bug, but is actually a symptom of a less-obvious error on my part (just not the one FontBakery is claiming). See further below for details.

* FAIL: Instance "Hairline UltCnd HiCntr Obl" wght value is "100.0". It should be "400.0" [code: bad-coordinate]
* ERROR: Failed with KeyError: 'YOPQ'
       File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/fontbakery/checkrunner.py", line 344, in _exec_check
         for sub_result in result:  # Might raise.
       File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/fontbakery/profiles/googlefonts.py", line 4140, in com_google_fonts_check_varfont_instance_coordinates
         if instance.coordinates[axis] != expected_instance.coordinates[axis]:

[tphinney]

Based on discussion in https://github.com/googlefonts/fontbakery/issues/2701 I suspected that maybe the FontBakery instance name parser does not recognize “Hairline” and therefore ignores that and assumes that this instance is regular weight.

While searching for a particular related string, I stumbled on Google Fonts Docs (WIP) at https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb#variable-fonts

Wish I had seen this sooner, but it was helpful. Google has specific expectations about weight and width naming of instances. Because I was working from the OpenType specs, I hit most of them, but because I didn’t know it was a requirement, and the specs sometimes list several synonyms, it wasn’t all correct.

The fix is to make sure all our weight and width instances are named per this, which requires "Thin" instead of "Hairline":

name	wght coordinate value
Thin	100
ExtraLight	200
Light	300
Regular	400
Medium	500
SemiBold	600
Bold	700
ExtraBold	800
Black	900
ExtraBlack	1000

name	wdth coordinate value
UltraCondensed	50
ExtraCondensed	62.5
Condensed	75
SemiCondensed	87.5
	100
SemiExpanded	112.5
Expanded	125.0
ExtraExpanded	150.0
UltraExpanded	200.0

[tphinney]

I am going to try to satisfy FontBakery and improve the font as well. I will

1) Make the STAT table values use the full desired names as per here, and also have an even richer set of instances (more stop points, especially for Slant and YOPQ). This would be:

• Weight: 9 steps
• Width: 8 steps
• YOPQ (contrast): 4 steps
• Slant: 3 steps

2) Have a smaller subset as the fvar named instances. The logical number from the above would be 864 (!), but I intend to reduce it below 200. List to follow later.

• For "Thin" and "ExtraLight" have only standard contrast
• For "Light" and Medium, have only "HiCntr" and no-cntr (delete all SmCntr and LowCntr)
• For SemiBold and Bold, delete all LowCntr
• For "Thin" have no UltCnd
• Have no predefined instances for "Active" (mid-slanted) except in the instances which are BOTH Medium+ weight, and Regular+ width.
• … more to come

[tphinney]

I have added the extra stop points for the STAT table. Still working on the specific instances for fvar; I have so far reduced them from 864 to 471. Will finish this process tomorrow.

[tphinney]

I did the reduction. BUT ... I was making a probably incorrect assumption, that FontBakery expects the shortened names in STAT but not in fvar.

Long style names in fvar might exceed a 31-character limit previously seen in some MS apps. I will do some testing in Word and see if there is still a problem.

[tphinney]

Reduced the fvar instances to about 130. Fairly manageable, and all the designspace corners are represented.

No massive issue remains in Word for Mac (although some minor stuff with what font it shows as currently selected).

The really long style names do make font menus and style display a bit problematic, due to stuff being visually truncated. I filed an issue with FontBakery. https://github.com/googlefonts/fontbakery/issues/2793