Better support for variable fonts

[dominikh]

I've noticed the following shortcomings in the handling of variable fonts / font variations:

• Given an opentype/api/font.Font or Face, it's not possible to determine what axes the font offers. Face has a Coords field that's documented as "It is empty for non variable fonts.", but since we create faces by simply wrapping fonts in them, Coords is also empty if Face.SetVariations hasn't been called, in which case the font is using its default values. I haven't found any other way to know which axes a font supports. I believe what we want is to expose the fvar and STAT tables of a font.
• fontscan is fully unaware of variable fonts. It doesn't use axes to fulfill requests, and footprint doesn't record which axes a font offers, either.

[dominikh]

Overall, this package seems somewhat designed around the WWS font model. For example, opentype/api/metadata.Describe prefers returning a family name that fits into the WWS model, which won't be a great fit for variable fonts.

[benoitkugler]

opentype/api/metadata.Describe prefers returning a family name that fits into the WWS model,

I'm not sure I'm following you here. Could you explain why would be the alternatives ?

[dominikh]

(This is somewhat orthogonal to variable fonts.)

This is the method in question:

// Family returns the font family name.
func (fd *fontDescriptor) Family() string {
	var family string
	if fd.os2 != nil && fd.os2.FsSelection&256 != 0 {
		family = fd.names.Name(namePreferredFamily)
		if family == "" {
			family = fd.names.Name(nameFontFamily)
		}
	} else {
		family = fd.names.Name(nameWWSFamily)
		if family == "" {
			family = fd.names.Name(namePreferredFamily)
		}
		if family == "" {
			family = fd.names.Name(nameFontFamily)
		}
	}
	return family
}

if I'm following the code correctly, this only uses the preferred family (aka the typographic family) if it fits the WWS model, and else it uses the WWS family (ignoring the fallbacks when either is empty).

Say we have a typographic family "Minion Pro" that has optical sizes "Caption" and "Display". Because optical sizes aren't part of the WWS model, this will have the WWS family names "Minion Pro Caption" and "Minion Pro Display". The typographic name, however, would be "Minion Pro", and group the two fonts under the same family.

https://learn.microsoft.com/en-us/typography/opentype/spec/name goes into more details on this. If you grep for The following is an example of family/subfamily naming for an extended, non-WWS family you will find the Minion Pro example.

In the end, it's a matter of what font model the application wants to expose to the user: R/B/I/BI, WWS, or the "extended" one which allows arbitrary axes (which is particularly useful with, but not restricted to, variable fonts.) Different kinds of applications will want access to the different sets of names, although modern, newly written software should arguably support the extended model.

[rcoreilly]

We encountered this issue at multiple levels in recent explorations:

• In the context of the Apple SF system fonts, which only list the rounded, arabic etc variants but miss the basic SF family.
• And many other fonts we were looking at are now being distributed in the variable format, and it was not immediately obvious why these were not working until we found this issue.

It looks like there is low-level support for all the elements (fvar, mvar, gvar) so as @dominikh notes, it seems (naively to me :) that it would just take a few tweaks to the higher level APIs to get this all working?

[benoitkugler]

We encountered this issue at multiple levels in recent explorations:

• In the context of the Apple SF system fonts, which only list the rounded, arabic etc variants but miss the basic SF family.
• And many other fonts we were looking at are now being distributed in the variable format, and it was not immediately obvious why these were not working until we found this issue.

It looks like there is low-level support for all the elements (fvar, mvar, gvar) so as @dominikh notes, it seems (naively to me :) that it would just take a few tweaks to the higher level APIs to get this all working?

Indeed, most of the low level logic is already implemented. At least, support for variations in font.Face should be quite easy to add. I'll try to sketch an API. I you have any suggestions or API usage examples, they're welcomed.