On 18/01/2017 07:04, Henri Sivonen wrote:
I'm in the process of rewriting our encoding converter infrastructure
in Rust. For a new implementation, it makes sense to support only the
Web-exposed encodings, that is, the encodings specified in the
Encoding Standard.

Currently, Firefox supports decoding non-Encoding Standard encodings
in one place: in TrueType system font names. TrueType fonts can
declare multiple names and the encoding of the names is specified on a
per-name basis.

Based on telemetry, Gecko sees these very rarely except for MacHebrew
on Mac, which is due to the set of system-bundled fonts containing a
font, Raanana, that declares one of its names in MacHebrew, and
Firefox enumerates all system fonts. This is not telemetry of the font
getting used but the decoder getting instantiated.

It also happens that Raanana doesn't declare its Hebrew name in
another way (Unicode or windows-1255), so removing support for
non-Encoding Standard font names has the effect of removing the
ability to specify Raanana by its Hebrew name in CSS. (I'm not
actually sure if Raanana is the only macOS-bundled font like this.)


Note that the current CSS Fonts 3 spec explicitly says that UAs are required to recognize localized font names:

"Some font formats allow fonts to carry multiple localizations of the family name. User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used or document encoding..."[1]

(The Hebrew name of Raanana is even included in the examples shown there!)

As you've noted, Chrome does not actually support this, so there is not full interoperability in this area; but if we decide to remove this support (and don't implement any of the possible workarounds) then I think we need to bring it up in the CSS WG and see if there is agreement on explicitly changing it in the spec. (I'm not sure how readily Apple and Microsoft will buy into that, as I believe there is historically some usage of localized font names on both macOS and Windows, though clearly Chrome hasn't considered it essential.)

Anyway, just wanted to point out that this is a spec issue, not something we should decide in isolation.

JK

[1] https://drafts.csswg.org/css-fonts-3/#font-family-prop

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to