[css-fonts-4] Installed font aliasing

[gsnedders]

The font matching algorithm contains:

For other family names, the user agent attempts to find the family name among fonts defined via @font-face rules and then among available installed fonts, matching names with a § 5.1 Localized name matching as outlined in the section above.

Where § 5.1 says:

Some font file formats allow font faces to carry multiple localizations of a particular string (e.g. family name or named instance). User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used, or document encoding.

This arguably doesn't match reality; for example fontconfig aliases various metric compatible families, which means that requesting "Helvetica" on most systems using fontconfig will find a font matching Helvetica, even though it's not any of the names that the font file format carries (e.g., here it will find Nimbus Sans).

I can see an argument that because it's a lower layer implementing this matching that it's conforming, whereas if the aliasing was done within the browser itself it wouldn't be conforming.

Regardless, we should probably take an explicit stance here (and that stance should probably be that this is conforming, given I don't see systems practically moving away from this).

To note: this came out from me trying to re-triage long-abandoned WebKit bugs, specifically from https://bugs.webkit.org/show_bug.cgi?id=6686 questioning whether "Garamond" should match either of "Apple Garamond BT" or "Adobe Garamond".

[svgeesus]

Some font file formats allow font faces to carry multiple localizations of a particular string (e.g. family name or named instance). User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used, or document encoding.

This originally said that matching was on the US-English localized name, regardless of locale. We got feedback on that and fixed it to allow any localization.

The fuzzy matching (Arial matching Helvetica, Helvetica Neue matching Helvetica, etc) is as you say a lower-level thing that we have no control over.

I agree that this should be conforming, although it is hard to specify (is Times a conforming match for Helvetica? Apart from the obvious, how can we say in spec prose that this is not a match?)

[litherum]

The spec shouldn’t be too prescriptive here. Just as in the discussions about font privacy, the spec can’t list exactly which fonts are installed on any machine, and it doesn’t make sense to try to test the difference between “both Helvetica and Arial are installed but their installed versions just somehow happen to have the same metrics” vs “only Helvetica is installed but Arial maps to it too.”

We should just add a normative “may” to the spec allowing user agents to add aliases if they feel their users would be served by having those aliases.

Background: many Chinese websites hardcode Windows-specific font names. We have added aliases in WebKit on iOS and macOS to fonts which have a similar design, in order to try to improve fidelity with the author’s intent. Having the freedom to do this is important for both browsers and operating systems to better serve their customers.

[svgeesus]

Okay so this one just needs a bit of "may" prose allowing such aliasing to be conformant.