Open drott opened 5 years ago
CC @behdad
Good points. I believe (and this text is also in Fonts 3) that
User agents that also match other full font names, e.g. matching the Dutch name when the current system locale is set to Dutch
actually is trying to say
User agents that also match other full font names, e.g. matching the Dutch name only when the current system locale is set to Dutch
which would indeed be an inconsistency (the it works on my machine
problem). Your proposed solution (matching all locales) would not produce inconsistency.
The definition of "...or the first localization if English is not available" is very arbitrary
It might also change as a font is revised, which would produce inconsistencies if new localizations are inserted rather than strictly appended.
I believe the "inconsistencies" mentioned are just supposed to ensure that font matching doesn't change when you modify your system language or move between countries.
This proposal seems to have 2 pieces:
Both of those are good for the Web platform.
I don't know how to implement these on top of CoreText. It exposes the PostScript name, the family name, the display name, and a few other names. Right now, WebKit just matches on PostScript name and family name (along with some other stuff that I don't think is spec-compliant).
The CSS Working Group just discussed Fonts
, and agreed to the following:
RESOLVED: local() matches against both full font name and postscript name
RESOLVED: Investigate whether it's practical to implement multi-locale name matching
I'd like to wait to do these edits until I can figure out if it's possible to implement.
It would be good if other imlementors also report back their implementability findings here on this issue
Perhaps @jfkthame can comment for FF.
Thanks @drott, useful!
IIRC, Firefox currently builds its own psname and fullname indexes (of English names only, or first available locale if no English present) for each font face, on all platforms except macOS, where it relies on CGFontCreateWithFontName, which helpfully matches on both psname and fullname.
(Unfortunately, https://developer.apple.com/documentation/coregraphics/1396330-cgfontcreatewithfontname doesn't specify how localized names are handled. A brief test seems to suggest that it does not match all locales.)
I guess we could collect all localized names on the platforms where we build our own indexes, rather than just the English (or first) name, but I'm not particularly keen; ISTM that it adds very little value.
I think the potential "inconsistency" the current spec text is trying to avoid is that the collection of localized names in a font may well vary over time/versions, and/or between locales where the font is made available, while still being "the same font" in the sense that src:local would be expected to match it. (Noting that src:local is appropriate when a particular typeface is wanted, but the exact version of the resource is not important.) Virtually all font resources include English names, so these can be matched reliably, but if src:local is allowed to match all localized names, this introduces the risk that an author may write src:local("Arial Fett")
, but on a user's system the equivalent font provides only "Arial Gras" as a localized alternative and so it is missed.
Declaring that src:local consistently matches against English names (and only those) is intended to minimize such issues.
@drott @litherum
Off-topic: does font-family
in Chrome and Safari still match fonts by Postscript name (Name ID 6) now (not in @font-face
)? See: https://bugs.chromium.org/p/chromium/issues/detail?id=641861#c19
Are there any drawbacks to using PostScript name
matching fonts? It seems like sometimes it would be easier to match the font the user wants.
data:text/html,<div style="font-family:Times-BoldItalic, sans-serif; font-size: 36px;">should be sans serif
Matching by PostScript name directly in font-family
, as in
font-family: Times-BoldItalic
is fundamentally in conflict with the CSS model of font properties. "Times-BoldItalic" is not a font family, it's a single face.
is fundamentally in conflict with the CSS model of font properties. "Times-BoldItalic" is not a font family, it's a single face.
@jfkthame Do you mean that the use of PostScript name conflicts with font-style and font-weight?
And font-stretch, yes.
Would you expect
font-family: Times-Italic;
font-weight: bold;
to result in the browser using Times-BoldItalic? Or what?
This does get more complicated, and there's currently no way to see which font the actual fallback goes to in Chrome DevTools, need to fix this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1365275.
There are basically two ways to go when specifying a font:
Option 1 is verbose, unmaintainable, and fundamentally incompatible with a tree-structured document, so CSS went for option 2 very early.
Relevant early discussions (1996)
@jfkthame Also, does Firefox match <family-name>
by looking for ID 16
in the font name table and then ID 1
? Can you provide a link to this code? Any other documentation on the matching process would be great, thanks so much!
FWIW, Chrome on macOS doesn't appear to match on PSnames in font-family
, at least for me....
data:text/html,<div style="font-size:30px; font-family: Times-BoldItalic, sans-serif;">hello world
gives me sans-serif, not Times.
Currently I'm only seeing Times-BoldItalic (incorrectly) used by Safari with that example.
Regarding family names, from the code at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/gfx/thebes/gfxFontUtils.cpp#1698 it looks like Firefox checks for both the Typographic Family (ID=16) and legacy Family (ID=1) names; if they're different it will include both in its table of available font families to match.
(With the aim of more consistent behavior across platforms, Firefox doesn't rely on OS APIs to look up fonts; instead, it queries the OS for the available fonts but builds an internal table of families and faces, so that it can apply the font matching algorithm itself rather than depending on what an opaque API may return for a given query.)
@jfkthame Strange, the PostScript name works for me(Chrome 121.0.6102.0, macOS 12.3).
Regarding family names, from the code at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/gfx/thebes/gfxFontUtils.cpp#1698 it looks like Firefox checks for both the Typographic Family (ID=16) and legacy Family (ID=1) names; if they're different it will include both in its table of available font families to match.
Thanks, your information is very informative.
@jfkthame Strange, the PostScript name works for me(Chrome 121.0.6102.0, macOS 12.3).
Strange indeed. But I'm on macOS 14.1 ... maybe some API behavior has changed that's affecting it?
But on Safari, the psname is still used.
FWIW, Chrome on macOS doesn't appear to match on PSnames
I believe @flackr was the one who implemented this in Chrome. (at least, he discussed implementing this in Chrome with me a few times)
@litherum Thanks, I see @flackr once submitted a PR https://github.com/web-platform-tests/wpt/pull/17004 for WPT.
FWIW Chrome still fails this test on mac. I added the test after doing an investigation which determined that Android did not in fact match PS names on font-family
per https://drafts.csswg.org/css-fonts/#font-families . This seems different than what's being discussed here where src: local(<name>)
seems to say that PS names should be matched.
For a
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
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).
[...]
[...]
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:
IDWriteFontSet::GetMatchingFonts
as well as FontConfig's pattern filtering functions currently do no restrict the search by locale.