Weight Axis for VF: please add one intermediate named instance every 100 units systematically

[thlinard]

The majority of VFs here, with weight axis, have a named instance every 100 units (depending on the extent of their weight axis). But, for VFs created before April or May 2021, every now and then a Medium or SemiBold weight, sometimes both, has been forgotten, although the API offers them.

I find myself with users who choose a font from https://fonts.google.com/, where all intermediate weights are displayed, and complain that I give them a "crippled" version when I give them the VF for software that only supports named instances (and giving them the static version is not a solution either, until #2616 is fixed).

Also, I'm not making a difference in this request between the fvar and STAT instances, but they don't always sync, so the problem overlaps sometimes with #3267.

Of course my request is not intended to ask that all the fonts switch to a weight axis that goes from Thin to ExtraBlack, but simply, if a VF has a weight axis that goes from 400 to 700 (for example), there should be Regular, Medium, SemiBold, and Bold instances.

• Alegreya lacks SemiBold
• Antonio lacks ExtraLight, Medium
• Arimo lacks Medium, SemiBold
• Assistant lacks Medium
• Caveat lacks Medium, SemiBold
• Cinzel lacks Medium, SemiBold
• Cuprum lacks Medium, SemiBold
• Domine lacks Medium, SemiBold
• Fraunces lacks ExtraLight, Medium, ExtraBold
• Ibarra Real Nova lacks Medium
• JetBrains Mono lacks SemiBold
• Josefin Slab lacks ExtraLight, Medium
• Kufam lacks ExtraBold
• Merriweather Sans lacks Medium, SemiBold
• Open Sans lacks Medium
• Red Rose lacks Medium, SemiBold
• Roboto Mono lacks SemiBold
• Sora lacks Medium
• Space Grotesk lacks SemiBold
• Varta lacks Medium

[thlinard]

Btw, it's the "expected behavior" requested by @davelab6 in fonttools/fontbakery#3031.

[thlinard]

When a variable font is onboarded to Google Fonts, we will provide instantiated static fonts for legacy applications. Thus, bear in mind Google’s API will automatically create all the 100x weights along the used range of the axis when producing static fonts, whether or not they are included in the designer's original design space.

https://github.com/googlefonts/gf-docs/tree/main/Spec#stat-table

[tiroj]

Type designers tend to think of families of static fonts in terms of discrete styles and weight variations, and typically do not include all possible intermediate weights. Very few traditional static font families include a named Medium weight, for instance; rather more contain a Semibold. This thinking carries across to the named instances of variable fonts, which tend to correspond to the conceived static font family structure, rather than being derived from the technical specification of the weight axis and CSS weight class named intervals. Put it another way, deciding what weights of a typeface are provided to the user as nominal parts of a family has been a kind of design or productisation decision.

A related issue is that if a variable font has been created that omits a named instance for a CSS weight class named interval, e.g. Medium, it may also be the case that the weight axis progression does not take that interval into account, i.e. that the Semibold instance is proportionally defined relative to the Regular and Bold without consideration of a hypothetical, intermediate Medium instance between Regular and Semibold. This may particularly be the case in a variable font that is derived from and seeks to match a pre-existing static font family.

Thus, bear in mind Google’s API will automatically create all the 100x weights along the used range of the axis when producing static fonts, whether or not they are included in the designer's original design space.

How does the API handle this in terms of avar applied to the wght axis? I am thinking about the case described above where, e.g. no Medium instance is accounted for in the weight progression, and hence the avar plots Regular-Semibold-Bold design space instances to 400-600-700 CSS weight class intervals. Is the 500 interval treated as halfway between 400 and 600 in the design space, or is an effort made to derive a proportional instance based on the design space relationship of the named instances?

[tiroj]

[For the record, I think type designer thinking needs to change in this respect, and provision of nominal weight variants should follow the technical spec rather than traditional productisation of static families.]

[thlinard]

Type designers tend to think of families of static fonts in terms of discrete styles and weight variations, and typically do not include all possible intermediate weights. Very few traditional static font families include a named Medium weight, for instance; rather more contain a Semibold. This thinking carries across to the named instances of variable fonts, which tend to correspond to the conceived static font family structure, rather than being derived from the technical specification of the weight axis and CSS weight class named intervals. Put it another way, deciding what weights of a typeface are provided to the user as nominal parts of a family has been a kind of design or productisation decision.

Hi John,

Yes, I'm aware of the reasons that have led us to the present situation, and I don't blame anyone. And yes, the arrival of VF leads to rethink the way static fonts or named instances in a VF are created.

But above all, it's now too late for Google Fonts VFs: users are already downloading fonts from https://fonts.google.com/ and putting them in Word or PowerPoint for Mac, or Apple Keynote. And in this situation, it's the VF format that seems legacy, and the static format that offers more possibilities: I really became aware of this situation when my users started complaining about VFs and asking me for statics, to have more weights.

From the moment when "API will automatically create all the 100x weights", it became necessary that the weight instances of a Google VF have also all the 100x weights, to allow compatibility between VF and statics.