New issue
Advanced search Search tips

Issue 876652 link

Starred by 2 users

Issue metadata

Status: ExternalDependency
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Task

Blocking:
issue 828317



Sign in to add a comment

Gather Spec Clarifications on src: local() matching

Project Member Reported by drott@chromium.org, Aug 22

Issue description

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."

Ideally we should strive to clarify which should be matched, one (which one on which platform?) or both (mandatory): Firefox at least on Linux, but I believe on all platforms, builds a list of all postscript and full font names and matches against that.

On Linux and Android, I will make our implementation behave the same way and match both.

> "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."

After discussing with Behdad we do not understand why we should only match against English. What would be the "inconsistencies" if a match succeeds that way?



 
Also: 
5.1. Localized Name matching
has

"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."

Sign in to add a comment