Closed Bug 1087147 Opened 5 years ago Closed 5 years ago
.1][zh-CN][Accessibility]A error Chinese charactor for Grayscale in Color filter
34.54 KB, image/png
56.12 KB, image/png
18.79 KB, image/png
1.57 KB, patch
|Details | Diff | Splinter Review|
Steps: 1)Choose language as "simplified Chinese" 2)Go to settings->Accessibility->Color filter. 3)wait for a window popped up , there are "invert","grayscale","contrast" Expected Results: grayscale should be "灰度" Actual Results: It's displayed a error Chinese charactor.--see the screenshot build version 20141020001201 Device: Flame kk v2.1(v180 base)
WFM on Firefox Simulator 2.1 & 2.2, and the translation is correct. Maybe is a graphics or font problem.
Whiteboard: [l10n] LocRun2.1 → LocRun2.1-1
Yes, this should not a translation error but a font issue. @Axel should this bug be transfer to somebody else? Br. Holy
Assignee: shaohua.wen → nobody
Status: NEW → UNCONFIRMED
Component: zh-CN / Chinese (Simplified) → Gaia::Settings
Ever confirmed: false
Product: Mozilla Localizations → Firefox OS
QA Contact: shaohua.wen
Note, on my mac, I don't see a difference between "灰度" and the screenshot. That said, I can't read the script, so I'm actually failing the "find 10 errors in these two drawings" game.
The two characters here are U+7070 "灰" U+5EA6 "度" Which of the characters is wrong? Can you be more specific about what's wrong with the rendering? Please provide a screenshot showing the desired/correct rendering. The "灰度" in comment 0 is not a reliable source for comparison, because how it looks will depend on the font that happens to be used locally. (I wonder if the characters are rendered from a Japanese font rather than a Chinese one; is that the basic problem here?)
U+7070 "灰" is the wrong character. I got a screenshot - gray-comparison.png: pic 1 is the original one pic 3 is the right one showed on non-Firefox OS device pic 2 is for Pinyin input, that means it also happens on other app.
It looks like "灰" is being rendered with a Japanese font, probably MotoyaLMaru. In fact, looking more closely at the screenshot, I believe we're seeing a mixture of fonts in general. For the unified Han range, it's using MotoyaLMaru for the characters supported by that font, and falling back to something else - probably Droid Sans Fallback - for those that aren't present in Motoya. This occurs, for example, in the word 反转 immediately above "grayscale". (I assume it's the "invert" option.) Here, the character 反 comes from the Japanese font Motoya, while 转 comes from the Droid font. That's why the weights of the two glyphs are not well-matched. I don't have a Flame device to test directly, but will try later to see if I can reproduce on a different device. I can think of a couple of issues worth checking: is the content tagged with the appropriate lang="zh" language code? Does it help if we add an entry to the B2G font prefs in all.js: pref("font.name.sans-serif.zh-CN", "Fira Sans,Droid Sans Fallback"); (and the same for zh-HK and zh-TW, I guess, as we don't want the Japanese font there either)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I wonder if I can "attach" data urls. Anywho, I checked a bit, and adjusted the pref, and the display changes to what I've put up/will put up. The original pref just lists FiraSans, adding Droid fallback seems to help. And yes, the lang='zh-CN' attribute is set on the html element.
nah, real file.
Attachment #8528392 - Attachment is obsolete: true
(In reply to Jonathan Kew (:jfkthame) from comment #7) > Does it help if we add an entry to the B2G font prefs in all.js: > > pref("font.name.sans-serif.zh-CN", "Fira Sans,Droid Sans Fallback"); > Oops; although that works, it's an abuse of the font.name pref, which is supposed to have a single font name. I meant to suggest adding pref("font.name-list.sans-serif.zh-CN", "Fira Sans,Droid Sans Fallback"); which should also work. (In reply to Axel Hecht [:Pike] from comment #9) > Created attachment 8528394 [details] > screenshot with adjusted prefs > > nah, real file. Great, that looks like we want.
looking at what fc-query says, FiraSans doesn't support Chinese at all, so adding it would only be useful if we intend to change that in the future. Otherwise, we can also just use Droid Sans Fallback as a single value?
The reason for listing Fira first, even though it doesn't actually support Chinese, is that many Chinese pages include some Latin text as well, and we want that to appear in Fira rather than using the (generally inferior) Latin glyphs from the Chinese font. (We use the same approach in desktop Firefox - at least on some platforms, I haven't checked them all.)
OK, so I propose we do this for now. (We may eventually want to replace Droid Sans Fallback altogether, e.g. with Noto fonts, but that's a separate issue.)
Attachment #8529776 - Flags: review?(l10n)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Comment on attachment 8529776 [details] [diff] [review] Prefer Droid Sans Fallback to a Japanese font for Chinese text on B2G Review of attachment 8529776 [details] [diff] [review]: ----------------------------------------------------------------- lgtm, r=me. I'm surprised that we're doing both font.name and font.name-list, but that's the same thing elsewhere, and consistency is cool.
Attachment #8529776 - Flags: review?(l10n) → review+
Yeah, it's all a bit funky. (The whole font prefs system is overdue for a rewrite, IMO, but I'm busy elsewhere for now.) https://hg.mozilla.org/integration/mozilla-inbound/rev/360b0c9a58c5
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.