[spec] fvar – named instances and the contents of the "static" directory

[graphicore]

I'm looking into updating Saira to VF https://github.com/Omnibus-Type/Saira/tree/master/Saira/fonts/gx

The VF family has 2 fonts: Saira[wdth,wght].ttf, Saira-Italic[wdth,wght].ttf
Each of it defines 63 named instances in fvar: (7 widths ✕ 9 weights)

On google/fonts we have 3 further families of the Saira super family (excluding Saira Stencil One): Extra Condensed, Condensed, Semi Condensed.

Thus, the VF version has the potential to replace all the width variant families on Google Fonts, plus adding more of its own width variants in one go, namely: Ultra Condensed, SemiExpanded and Expanded

Looking at the named instances in fvar, I'd expect the static directory to contain 126 fonts, 63 each for the upright plus italic VFs. (And I kind of think that makes sense)

However, looking into the (updated) spec:

Fvar instances

[...]
We only allow weight and italic particles. If a font contains additional axes, they must not be mentioned in the instance names and the coordinates for each instance must be set to reasonable default e.g if your font contains a wdth axis, you don't want every instance's wdth coordinate value to be set to Condensed (75) you would set it to Normal (100).

• Ok, so 18 fonts in static for upright plus italic.
• What does this mean for the other existing siblings of Saira? Should these be updated with the same Variable fonts, but with changed name tables and different fvar instances? However, then, wdth would be set to something else than Normal (100)!
• Will we ever replace Saira{WeightVariation}-sibling families with just one VF family?

Saira has other problems with named instances , but I believe these are off topic.

[davelab6]

Ok, so 18 fonts in static for upright plus italic.

Yes, that seems like a safe starting point that allows us to proceed and then figure out what to do about the other styles later, without making an early decision that will be hard to change later.

What does this mean for the other existing siblings of Saira?

We don't touch them, for now.

Will we ever replace Saira{WeightVariation}-sibling families with just one VF family?

That is the plan, but the GF engineering team need to figure out how that will happen.

[m4rc1e]

Thanks for the response Dave! I was halfway through an essay and you've covered it more succinctly.

Re siblings: One solution is to simply hide the sibling wdth families in the catalogue, once the variable font is on Google Fonts. We'll keep the sibling width endpoints so existing users won't be affected.

[davelab6]

Please post more details if you still have them written :)

[davelab6]

I also wonder that if type designers have already included the named instances that we require, and then more than that, maybe we don't have to ask them to remove them - but we only include statics for the 18 styles of a pre-vf family.

[m4rc1e]

Sorry hit backspace. Here's some bullet points from my cancelled msg.

• If we cannot delist a sibling family from the catalogue (imo the best option). We can use fontTools varLib.instancer to make a a VF for the sibling families quite easily by pinning the wdth axis.
• Having decent STAT tables will still allow designers to access more esoteric instances, albeit using a different UI panel.

I also wonder that if type designers have already included the named instances that we require, and then more than that,

Every VF I've seen which contains multiple axes always includes all the instances we need + a shed tonne more. :-)

I'm tempted to update the gf-glyphs-scripts fix_fonts script to remove redundant instances. However, this may upset designers. An alternative is to update gftools fix-vf-meta and let the script prune instances that we don't want.

[rsheeter]

If we cannot delist a sibling family from the catalogue (imo the best option)

We can delist width families. IMHO we should do so when we onboard a vf with wdth.

We can use fontTools varLib.instancer to make a a VF for the sibling families quite easily by pinning the wdth axis.

I suggest we don't worry about this. If we delist them we're good. We might in future map them over to an appropriately positioned VF when generating css.

[davelab6]

We can delist width families. IMHO we should do so when we onboard a vf with wdth.

Users seeking the previously available styles ought to have a way to find how to access them, and not have their links broken.

Perhaps there are some cheap ways to achieve this: Eg, explain what happened in the DESCRIPTION file of the remaining 'parent' family; and 302 redirect de-listed and VF-upgraded specimen pages to the parent (eg https://fonts.google.com/specimen/Saira+Condensed redirects to https://fonts.google.com/specimen/Saira)

[davelab6]

We can use fontTools varLib.instancer to make a a VF for the sibling families quite easily by pinning the wdth axis.

I suggest we don't worry about this. If we delist them we're good. We might in future map them over to an appropriately positioned VF when generating css.

The possible exception to that could be super high traffic sibling families, but that can be done on a case by case basis.

[rsheeter]

super high traffic sibling families

I was curious so I looked in analytics. It appears there are no sibling families with high traffic specimen pages.

[graphicore]

Everyone, thanks for the answers, very interesting stuff!

With:

Ok, so 18 fonts in static for upright plus italic.

Yes, that seems like a safe starting point that allows us to proceed and then figure out what to do about the other styles later, without making an early decision that will be hard to change later.

My main question was answered, so I'm closing this. Feel free to reopen, if you feel there's more to say.