[css-fonts-4] src: local() font unique name matching ambiguous & restricts matched locale #3177
Description
For a
@font-face {
src: local(<fontname>)
}
definition, the rules in the specification how <fontname> is to be matched seem ambiguous and unnecessarily restrictive with regards to the locale against which <fontname> is matched.
From https://drafts.csswg.org/css-fonts/#descdef-src
For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts. Which type of name is used varies by platform and font, so authors should include both of these names to assure proper matching across platforms. Platform substitutions for a given font name must not be used.
As far as I can tell, Firefox implements matching against full font name as well as postscript name on all platforms. This is also what I have so far implemented on all Chrome platforms. I suggest we standardize that UAs must match against both to clarify matching expectations and remove redundancy in specified src: local() values (compare the example in the spec suggesting to place multiple local() values).
[...]
Just as a
@font-facerule specifies the characteristics of a single font within a family, the unique name used with local() specifies a single font, not an entire font family. Defined in terms of OpenType font data, the Postscript name is found in the font's name table, in the name record with nameID = 6 (see [OPENTYPE] for more details). The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows.
[...]
For OpenType fonts with multiple localizations of the full font name, the US English version is used (language ID = 0x409 for Windows and language ID = 0 for Macintosh) or the first localization when a US English full font name is not available (the OpenType specification recommends that all fonts minimally include US English names). User agents that also match other full font names, e.g. matching the Dutch name when the current system locale is set to Dutch, are considered non-conformant. This is done not to prefer English but to avoid matching inconsistencies across font versions and OS localizations, since font style names (e.g. "Bold") are frequently localized into many languages and the set of localizations available varies widely across platform and font version. User agents that match a concatenation of family name (nameID = 1) with style name (nameID = 2) are considered non-conformant.
I do not understand the reasoning for preferring US English to avoid "matching inconsistencies".
What would be an example of such a matching inconsistency? I believe a matching inconsistency or ambiguity would occur if matching locales widely would create ambiguities in which font to choose. IMO, it is very unlikely that a full font name or postscript name in one locale accidentally collides with a different font's full font name or postscript name in a different locale.
Hence I argue we should more broadly match all locales that exist in the name table for postscript name as well as full font name:
- It increases chances of success of local matching for the user/page author. (In my opinion without causing matching inconsistencies)
- It improves consistency within the specification itself, compare section 5.1 Localized Name Matching where font family matching is actually required to take all localizations into account.
- From an implementation point of view, I don't see any obstacles. This mostly means enumerating through the name table, filtering by name record id, and just not dropping non-English localizations. The definition of "...or the first localization if English is not available" is very arbitrary: We can improve upon that by matching all. As an additional data point, OS level implementations such as
IDWriteFontSet::GetMatchingFontsas well as FontConfig's pattern filtering functions currently do no restrict the search by locale.