1648474 - Japanese fonts name MOJIBAKE and indicates English font name in preferences and Thunderbird Compose window.

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Alice0775 White]

Attachment: screenshot, Nightly79.0a1 .VS. 78.0RC

[Tracking Requested - why for this release]:
Defect again.
Some Japanese font name MOJIBAKE in preferences and Thunderbird Compose window

+++ This bug was initially created as a clone of Bug #1606744 +++

Reproducible: always

Steps To Reproduce:

1. Make sure that Windows display language is Japanese on Windows 10
2. Install Japanese fonts, (you can download and install it from https://www.epson.jp/dl_soft/readme/9296.htm )
3. Start Nightly
4. Open about:preferences > General
   Language and Appearance, Fonts and Colors > Advanced
   Open font select drop down

Actual Results:
MOJIBAKE Font name, See attached screenshot

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a0af6d53c082d97a83c9c0891c36e35331330880&tochange=ed8d5ec80203d89a34e68220e7d8476a22f9b867

Comment 1

[Alice0775 White]

Attachment: screenshot2 default font name for Japanese, Nightly79.0a1 .VS. 78.0RC

And default font name are indicated in English on Nightly79.0a1, in Japanese in 78.0RC, see attached screenshot2.

Comment 2

[Jonathan Kew [:jfkthame]]

The root of this problem is actually that those Epson fonts are broken: in their 'name' table, they have name strings tagged as MacRoman encoding, English language -- but they are actually encoded in legacy double-byte MacJapanese, and when interpreted as MacRoman the Japanese characters in them appear as garbage. We can see this if we install the fonts in Windows, and then look in the font list in Preferences when running current (release) Firefox, without enabling shared-fontlist, on an English system.

On a Japanese-language system, the names look OK because the current code gets the name strings corresponding to the system locale. Currently with the shared-fontlist, this doesn't happen: the "English" names (which in this case are garbage) are treated as canonical.

So there are two things to do here: (1) if possible, prefer locale-appropriate names for display in the font list (as current Release does); and (2) see if we can figure out some way to ignore the broken "English" names in these fonts, as they're never good to display on any system.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Regressing bug was backed out, but I'll leave this open while investigation continues.

Comment 4

[Jonathan Kew [:jfkthame]]

FWIW, I just checked and the font list in Chrome (when running in an English locale, at least) shows the same garbled names for these Epson fonts.

We should at least try to make them appear correctly on Japanese systems, though.

Comment 5

[Masatoshi Kimura [:emk]]

I confirmed that Chrome shows the garbled names even with a Japanese locale. No other fonts have Japanese names (MS Gothic, Meiryo, Yu Mincho instead of MS ゴシック, メイリオ, 游明朝). Apparently Chrome uses a hard-coded English locale for font names.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1648474 - patch 1 - Include all localized DirectWrite font family names in the font list. r=jwatt

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1648474 - patch 2 - Localized names other than the system locale (or default English) should not be exposed in the Preferences UI font list. r=jwatt

Depends on D87660

Comment 8

[Jonathan Kew [:jfkthame]]

The approach here is to create duplicate Family records with the localized names as part of font-list initialization. The DirectWrite API already has these names in the IDWriteLocalizedStrings that we get from each family, so we can easily record all the names (there's usually just one, except in the case of some CJK fonts).

The only downside of this is that the fonts will show up under both English and localized names in the Preferences font list. To avoid that, we can keep track of which names are for an "alternate" locale (not the current system locale) and hide those from the Preferences list, although they'll still be accepted if used in font-family.

To address the Epson fonts with bad "English" names, we can check if the supposedly-English name is non-ASCII; if so, and if there's an alternative localization also present, choose that to present instead.

(The overwhelming majority of fonts don't have multiple localizations of the family name anyhow, so it's a non-issue for them.)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73f5aead2bda
patch 1 - Include all localized DirectWrite font family names in the font list. r=jwatt
https://hg.mozilla.org/integration/autoland/rev/df28de524167
patch 2 - Localized names other than the system locale (or default English) should not be exposed in the Preferences UI font list. r=jwatt

Comment 10

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/73f5aead2bda
https://hg.mozilla.org/mozilla-central/rev/df28de524167