- From: Sam Sneddon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Dec 2020 17:47:06 +0000
- To: public-css-archive@w3.org
gsnedders has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts-4] Installed font aliasing == The [font matching algorithm](https://drafts.csswg.org/css-fonts-4/#font-style-matching) 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](https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/master/conf.d/30-metric-aliases.conf), 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". Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5819 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 December 2020 17:47:07 UTC