Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Henri Sivonen]

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

https://hsivonen.com/test/moz/raanana.html indicates that Safari
supports specifying Raanana by its Hebrew name but Chrome doesn't.
That is, by making this change we'd end up with Chrome parity but
would break Safari parity. Sites that have been tested in Chrome can
already be expected to refer to Raanana at least by its Romanized
name.


Answers to anticipated questions:


Won’t this make our TrueType support incomplete?

We already don’t support all possible legacy TrueType font name
encodings, and the names only matter for fonts installed on the
system, so as long as present-day OS-bundled fonts work (well enough)
we don't need to support everything that ever existed.


How rare are the cases other than MacHebrew-on-Mac?

Except for MacHebrew-on-Mac, each of the non-Roman, non-Cyrillic
single-byte Mac encoding is seen in 0.00% of Firefox sessions. Even in
the cases where this isn't absolutely zero (i.e. it's only zero to two
decimal places), there are further mitigating factors: 1) The fonts
may be declaring their name(s) also in Unicode or in a supported
Windows legacy encoding. 2) Fonts that are this rare don't make sense
to specify on Web sites except for fingerprinting purposes. (That is,
when Web authors specify fonts that reside on the user's system as
opposed to being downloaded from the Web, they tend to want to specify
widely-available system-bundled fonts.)


Are Web Fonts affected?

No. The @font-face mechanism points to fonts by URL and ignores the
names declared within the font files.


Can Raanana still be used?

Yes, by using the Romanized name "Raanana".


Are there alternatives to removing support for the Hebrew name of Raanana?

Yes, but they are more complex than just removing support. This is the
opportunity for interested parties to advocate for the alternatives,
though. The alternatives are:

* Including a MacHebrew decoder in Gecko outside the normal converter
infrastructure only for the purpose of decoding system font names.

* Decoding MacHebrew font names on macOS only by calling the system
converter API for MacHebrew only.

* Including a special-case check for the name Raanana when enumerating
the system fonts and adding a synthetic entry for the Hebrew name in
Gecko's data structures when the Romanized name is seen (and doing the
same for other macOS-bundled Hebrew fonts that have a Hebrew name in
MacHebrew only if other such fonts exist). (This is my preference for
an alternative to outright removal of the ability to specify Raanana
by its Hebrew name.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Jet Villegas]

* Including a special-case check for the name Raanana when enumerating
> the system fonts
>

My preference as well, though I'm not convinced it's worth doing.

The Wikipedia page for the city of Ra'anana [0] marks up the city's Hebrew
name as:

<span class="script-hebrew" style="font-size: 115%; font-family: Alef, 'SBL
BibLit', 'SBL Hebrew', 'David CLM', 'Frenk Ruehl CLM', 'Hadasim CLM',
Cardo, Shofar, David, 'Ezra SIL', 'Ezra SIL SR', 'Noto Sans Hebrew',
FreeSerif, 'Times New Roman', FreeSans, Arial;" dir="rtl">רַעֲנָנָה</span>‎

The Hebrew version [1] doesn't specify Hebrew fonts at all.

I often use Wikipedia as my unusual font reference site, though it's
certainly not exhaustive. Then again, if there's one place to use the
רַעֲנָנָה font, it would be in רַעֲנָנָה :-)

[0] https://en.wikipedia.org/wiki/Ra'anana
[1] https://he.wikipedia.org/wiki/%D7%A8%D7%A2%D7%A0%D7%A0%D7%94

[Jonathan Kew]

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

[Henri Sivonen]

Forgot the bug link: https://bugzilla.mozilla.org/show_bug.cgi?id=1331859

On Wed, Jan 18, 2017 at 11:38 AM, Jonathan Kew <jfkt...@gmail.com> wrote:

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

Seems messy. Let's not break the Hebrew name of Raanana then.

(For others: Per bug comments, let's go with CoreFoundation decoding
for MacHebrew font names on Mac.)

[Geoffrey Sneddon]

On Wed, Jan 18, 2017 at 9:38 AM, Jonathan Kew <jfkt...@gmail.com> wrote:
> 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

Is it currently the case that all major APIs (i.e., CoreFoundation,
GDK, Direct2D, FreeType, etc.) read all localisations of family name?
Like, will Direct2D read MacHebrew encoded names? If not, then the
only way to be compliant with what Fonts 3 says is for the browser to
support every possible character encoding in OpenType (IIRC that's a
closed set?) and convert it to something the system API can read?

I believe it's not, and I doubt anyone is going to implement that,
hence I'd guess the spec needs to change anyway.

/g