Variable Font Origin

I have a 6 master Variable font with two axes (width and weight). The masters are at the Extremes so the Regular style (Normal width) is just an instance. If I don’t set the Variable Font Origin parameter the styles in Adobe menus look nicely sorted and everything seems to work, but FontBakery check gives me a FAIL:

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 Allotrope-Variable.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 'Compressed Thin' instance has the same coordinates                   
      as the default instance; its subfamily name should be 'Regular' [code:
      invalid-default-instance-subfamily-nameid:258]                        

 FAIL 'Compressed Thin' instance has the same coordinates                   
      as the default instance; its postscript name should be                
      'AllotropeVariable-Regular', instead of                               
      'AllotropeVariable-CompressedThin'. [code:                            
      invalid-default-instance-postscript-nameid:259] 

If I add the parameter Variable Font Origin and set it to a master (e.g. Wide Regular) the Wide style in Adobe menus gets moved to the top of the style list (which is confusing for the user) and I get another FAIL from FontBakery:

FAIL 'Wide' instance has the same coordinates as the                       
      default instance; its subfamily name should be 'Regular' [code:       
      invalid-default-instance-subfamily-nameid:344]                        

 FAIL 'Wide' instance has the same coordinates as the                       
      default instance; its postscript name should be                       
      'AllotropeVariable-Regular', instead of 'AllotropeVariable-Wide'.     
      [code: invalid-default-instance-postscript-nameid:345]   

So I guess adding the Regular instance as master would solve this to an extent. But it seems ridiculous to increase the size of the Variable font file by adding masters just for this. Is there another way to solve it?

This is just the temporary implementation of Adobe. Likely to change, again.

The naming of the variable font must reflect the default style.

If I decide to add the Regular instance as master in order to select it for the Variable Font Origin, is the interpolation going to be changed for other instances? Should I then also add two more masters for the Thin and Heavy on the Normal Width axis, or not? Here’s the setup:

As far as I remember, even if you add a Regular master (and yes, most likely those two others too), you will get two Regulars in the same way. Adobe wants origin to be first, and the only way to get nice instance sorting is to set origin to the first instance’s master (which is probably what Glyphs did in your case), then it doesn’t duplicate. Regular origin probably makes sense in many places, but not for Adobe :frowning:

Thanks for the reply! Menu sorting is my secondary concern. Even Adobe’s own Variable fonts have a style on top of the menu (only theirs is named Default – could be a good solution for Glyphs too). My main goal is to solve this FAIL I get from FontBakery:

And the only way I see that solved is by adding more masters. Which I really don’t want to do because it will increase the file size and is plain wrong. But it seems I’ll have to :expressionless:

Can you post a screenshot of your variable font setting? As well as your instance setup?

If you want your variable fonts primarily to work in and for Adobe apps, best heed their advice and just leave the default instance as the first instance (=first master). Or are you hell-bent on having Regular as your default instance?

Thanks for the reply! I get the perfect menu sorting in Adobe menus if I don’t set the Variable Font Origin. But then the font doesn’t pass the Adobe Fonts FontBakery check. You can see the FAIL message in the original post.

I wonder what their requirement is based on and whether it is something to worry about. Since it comes from Microsoft, I bet it has to do with MS Office support, which loves RIBBI.

The “requirement” is that the check-adobefonts gives no fails on the variable font. At least that’s what is requested.

I’m sure you can do some explaining and show that it works fine. Out of interest, could you show your instance metadata for your default instance? Maybe adding some extra name table parameters could help.

1 Like

There are some of those test that require that the origin master is at weight 400 and be the same as the “Regular” instance. But that doesn’t make any sense as that means in a lot of cases to blow up the file size for no reason. And file size savings where one of the main selling points of variable fonts.

1 Like

I don’t think any fontbakery check requires that there is a master at the axis default.

Many of the quoted fontbakery fails show that the messaging is kind of backwards. When it says

‘Compressed Thin’ instance has the same coordinates as the default instance; its subfamily name should be ‘Regular’

it would be more useful to describe it the other way round, i.e.

  • “Compressed Thin” is at the same location as the default instance
  • The subfamily name for the default location (found in the Exports–VF setting) is apparently “Regular”, which does not match the default instance’s name

Solution:

  • Change the “Name” in the Exports–VF setting to “Compressed Thin”, and
  • Deactivate the instance of the same name

I’ve added a demo project that corresponds to your 2-axis setup and passes nearly all fontbakery checks. Fontbakery still complains that

  • “The “wght” axis coordinate of the “Bold” instance must be 700. Got None instead” – If there is no instance called “Bold”, it can’t be at weight 700, or can it, fontbakery? Ignore this …
  • “OS/2 usWeightClass is ‘400’, but should match fvar default value ‘100.0’” – The error message is correct; I don’t know any way to influence this inside Glyphs, Glyphs should add a “WeightClass” parameter on the VF setting

Glyphs-VF-Test.zip (5.7 KB)

4 Likes

Perhaps this was the reason:

The problem in Mac Word is that it appears that if a font only has a master at either end of the designspace (and lacks one at the “Regular” location) that it will never be able to find the “Regular” location, regardless of the ‘elidable’ state.

Found it here: STAT table errors in variable fonts · Issue #2391 · google/fonts · GitHub

I don’t even understand what that means exactly :wink:

AFAIK Word doesn’t use the STAT table entries to construct its font style menu, it relies on instances being defined in the fvar table for that.

1 Like

I’d like to take a moment and clear up several misconceptions here.

In my opinion, things make more sense when you really think of a VF as a single font with all the instances “growing” from it – rather than looking at an axis-based spreadsheet. This single font is the origin of your designspace, it is where all the axes meet.

  • The default font does not have to be “Regular” – in the OP’s case the default would be “Compressed Thin”
  • If you however want Default == Regular, you must include a Regular master. That’s not Adobe’s doing, that’s just the design of VF.
  • Whatever your Default ends up being, the “basic” font info (OS/2, name, etc.) should reflect that and not necessarily “Regular”

@GeorgSeifert: There are some of those test that require that the origin master is at weight 400 and be the same as the “Regular” instance

This is not accurate. There is absolutely no necessity to insert a Regular master into your designspace, just to appease FontBakery checks.

@jkutilek: I don’t think any fontbakery check requires that there is a master at the axis default.

I don’t think there needs to be a check for that, because a VF could simply not be built without having masters at the axis defaults. The combination of axis defaults again is at the position of that origin master :slight_smile:

Thank you also for pointing at the backwards wording in the FontBakery test – this will be addressed – just as we’ve already already addressed the “no Bold instance” problem.

4 Likes

This is great news! Thank you for taking the time to explain.

I worked on this yesterday and can now export a font that passes all Adobe tests. I’ll check if the other test show any relevant issues an then upload a new version later today.

4 Likes

THAT is great news. @GeorgSeifert you are the best!

Ok – now I see what you mean – so the current setup of the corners of the cube, could be theoretically shifted to ends of the axes (would require more fiddling with the points to get the extrapolations right) but one less master to worry about I suppose :slight_smile: I’ll keep that in mind in future projects! Thx Frank!

@jkutilek: I don’t think any fontbakery check requires that there is a master at the axis default.
@frankrolf: I don’t think there needs to be a check for that, because a VF could simply not be built without having masters at the axis defaults. The combination of axis defaults again is at the position of that origin master :slight_smile:

My words were chosen poorly. By axis default, in this case I meant the “regular value” of the axis as defined in the spec: wdth 100, wght 400, ital and slnt 0, opsz 10–16.