Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Not sure what to do about failing "com.adobe.fonts/check/varfont/valid_default_instance_nameids"

See original GitHub issue

Observed behaviour

I have a font building from FontMake, and it has a fairly normal designspace.

The default instance is “Light,” and the name IDs are as follows:

nameID=1 Shantell Sans Light
nameID=2 Regular
nameID=3 1.005;@;ShantellSans-Light
nameID=4 Shantell Sans Light
nameID=5 Version 1.005;[1aad51c31]
nameID=6 ShantellSans-Light
nameID=8 Arrow Type
nameID=9 Stephen Nixon, Anya Danilova, Shantell Martin
nameID=11 https://arrowtype.com
nameID=12 https://github.com/arrowtype/shantell-sans
nameID=13 This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL
nameID=14 https://scripts.sil.org/OFL
nameID=16 Shantell Sans
nameID=17 Light

I think this is all correct… however, I get the following fail:

    com.adobe.fonts/check/varfont/valid_default_instance_nameids
    Validates that when an instance record is included for the default instance, its subfamilyNameID value is set to either 2 or 17 (or something with the same value as 2), and its postScriptNameID value is set to 6 (or something with the same value as 6).
    with fonts/shantell_sans-for-googlefonts/ShantellSans[BNCE,IRGL,TRAK,wght].ttf

      Rationale:                                                                
                                                                                
      According to the 'fvar' documentation in OpenType spec v1.9.1             
      https://docs.microsoft.com/en-us/typography/opentype/spec/fvar            
                                                                                
      The default instance of a font is that instance for which the coordinate  
      value of each axis is the defaultValue specified in the corresponding     
      variation axis record. An instance record is not required for the default 
      instance, though an instance record can be provided. When enumerating     
      named instances, the default instance should be enumerated even if there  
      is no corresponding instance record. If an instance record is included    
      for the default instance (that is, an instance record has coordinates set 
      to default values), then the nameID value should be set to either 2 or 17 
       or to a name ID with the same value as name ID 2. Also, if a             
      postScriptNameID is included in instance records, and the                 
      postScriptNameID value should be set to 6 or to a name ID with the same   
      value as name ID 6.                                                       
                                                                                
     FAIL 'Light' instance has the same coordinates as the                      
          default instance; its subfamily name should be 'Regular' [code:       
          invalid-default-instance-subfamily-nameid:344]                        

    Result: FAIL

Expected behaviour

The check message is somewhat confusing, and it took some digging around github and some experimentation with TTX to pass the check, before I understood what it was actually saying.

From my experimentation, I found that:

The default instance and its expected names (for the check) is determined in fvar, where the name IDs subfamilyNameID="265" (Light) and postscriptNameID="320" (ShantellSans-Light) are referenced.
If I change name ID 1 to Shantell Sans and name ID 2 to Light, I pass the check.
Therefore, the check is basically saying that name ID 2 should be Light rather than Regular, which implies that name ID 1 should simply be the family name.

However, based on some GH issues, it seems that perhaps the check is outdated/incorrect/overly-strict:

https://github.com/googlefonts/fontmake/issues/902
- https://github.com/MicrosoftDocs/typography-issues/issues/946

My main question

Who is more correct – FontMake, or @miguelsousa?

Is it a matter of opinion, or is there anything that explains why FontMake makes names 1 and 2 in the way it does?

If it is a matter of opinion, can Google Fonts coordinate the expectations between FontMake and FontBakery?

If we do keep the check…

I only vaguely understood what the rationale is telling me, and I don’t understand much at all what action it is suggesting that I take. I understand that writing a clear check rationale is tricky, as readers have such a wide range of technical understanding.

However, I think ideally, the fail messages would explain:

What specific name ID(s) are incorrect
What specific name ID(s) should be changed, and to what.
- Is it suggesting that name ID 2 should be Light? If so, should I edit this
- If it is not suggesting I change a name ID, what is it suggesting? Is it saying that I should make the default instance a “Regular” (which would require adding one or more sources/masters to the font)?
If there is something that can be set in a designspace file to produce the desired result from a FontMake build, what is recommend?