Take secondary locales into account for glyph selection, especially in the context of Han Unification disambiguation

UNCONFIRMED
Unassigned

Status

()

defect
P3
normal
UNCONFIRMED
3 years ago
Last year

People

(Reporter: yukawa, Unassigned)

Tracking

(Blocks 1 bug, {intl})

Trunk
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: gfx-noted)

Attachments

(2 attachments)

Reporter

Description

3 years ago
Steps to reproduce the issue:
1. Download and flash Android N developer preview NPC56P into Nexus 6P (this is not device specific though) with system locale en-US.
   http://developer.android.com/preview/download.html
2. Enable Google Japanese Input in the system settings (or install whatever Japanese IME you want to use).
3. Install Firefox for Android nightly 48.0a1 (2016-03-09) into Android N developer preview NPC56P.
4. Launch Firefox nightly, go to "data:text/html,<textarea>"
5. Type "忍者" on the textarea.
6. In the system settings, add Japanese as the secondary language.

Expected behavior:
"忍" is rendered with a Japanese glyph after step 6.

Actual behavior:
"忍" is rendered with a Chinese glyph after step 6.

Chromium bug:
http://crbug.com/593511

Additional information:
In Android N, we are working hard to enable users to specify more than one system languages, which will be exposed to applications as an ordered list of Locales.
http://developer.android.com/preview/features/multilingual-support.html

I'm not familiar with how (system) locale change event has been handled in Gecko, but seems that you can call newConfig.getLocales() instead of newConfig.locale in the following place to get the full list of system languages that the user specified.
http://hg.mozilla.org/mozilla-central/file/93156962855d/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#l2206

It would be great if secondary locales are taken into account for glyph selection in Firefox.

Thanks!
Reporter

Comment 1

3 years ago
Posted video Expected behavior
This is how built in EditText works.
Reporter

Comment 2

3 years ago
Posted video Actual behavior
This is how Firefox for Android nightly 48.0a1 (2016-03-09) behaves.
I don't know who are working in gfx for Android, though...

In the old thebes, we checked system locale in same situation on Windows. However, I don't find the code in current thebes. So, I'm not sure which push log tells us who is active contributor for here.
Component: Internationalization → Graphics: Text
Keywords: intl
We changes fonts by language of HTML instead of input source.  So If lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.
(In reply to Makoto Kato [:m_kato] from comment #4)
> We changes fonts by language of HTML instead of input source.  So If
> lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.

How about the language information isn't available or non-CJK but the contents have Kanji characters?

E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo lang="en-US">漢字</foo>.
Reporter

Comment 6

3 years ago
Just FYI, I've uploaded screenrecords here too in case you can watch these movies more easily there.
https://drive.google.com/open?id=0ByZK1hhvVhpVTEt1ZVA0VEw3TFU

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?
> 
> E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo
> lang="en-US">漢字</foo>.

Yeah, that's the problem, and my understanding is that we would eventually need multi-level fallback rules, e.g. en-US > ja-JP > zh-TW, for each context.

As for web browsers, I think it makes sense to put the highest priority on lang attribute, but when it is not sufficient to disambiguate something, it would be great if the browser can treat the system locales as fallback languages.

https://drive.google.com/open?id=0ByZK1hhvVhpVWlJNbFF5emZscE0 is an example where the order of secondary languages matters.
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> (In reply to Makoto Kato [:m_kato] from comment #4)
> > We changes fonts by language of HTML instead of input source.  So If
> > lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.
> 
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?

Application locale.  But Android implementation of nsILocale is pretty broken because it doesn't use Java code.  So if locale is changed, Gecko for Android doesn't know it
gfxPlatformFontList generates font list per locale data.
Depends on: 1256217
Blocks: 1256374
Depends on: 1337078
You need to log in before you can comment on or make changes to this bug.