69139 - RFE: X font fallback should look in doc's langgroup before random

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement, P1)

Description

[kill this account]

when the glyph is not available the fallback code should look in langgroup fonts 
before enumeration all font which gives a random selection

This should be the fallback just after looking for a subplane.
See: http://bugzilla.mozilla.org/show_bug.cgi?id=67732

Comment 1

[kill this account]

If the page is unicode (ie: does not have a langGroup) use the langGroup of the 
primary font. The primary font's langGroup is a strong hint from the user as to 
which langGroup they prefer.

Comment 2

[Brian Yuan]

Attachment: Wrong glphy is used for Simplified Chinese Character in GBK locale (0xCDA3)

Comment 3

[Brian Yuan]

Sun Asian Localization center thinks this is a P1 (I don't have the permission
to do this in bugzilla) and a showstopper, the good example is the first
Character in the translation of menu
'Stop', it is displayed using a wrong glyph which might come from a Japanese
fonts file.

BTW, it might be a very serious problem if Mozilla/NSCP 6.0 doesn't support
GB18030 which is a supperset of GBK and is a mandatory Standard in P.R.China.

Comment 4

[Brian Yuan]

The above problems are found in zh.GBK locale using the default fonts setting.
After I added gbk-0 fonts to the prefs.js, the problems are fixed, so the fix we
need is to use gbk-0 fonts for all of the none GB2312 Characters in zh_CN
language.
Thanks.
Brian.

Comment 5

[kill this account]

When you say

   "After I added gbk-0 fonts to the prefs.js, the problems are fixed"

do you mean that you selected a Simplified Chinese font in the font preference 
dialog?

Comment 6

[Brian Yuan]

No, I manually created a GBK Profile using ./mozilla -profileManager and added
the following lines in ~/.mozilla/GBK/dn2wdw4q.slt/prefs.js:
user_pref("font.name.monospace.zh-CN", "dt-interface user-gbk-0");
user_pref("font.name.sans-serif.zh-CN", "dt-interface user-gbk-0");
user_pref("font.name.serif.zh-CN", "dt-interface user-gbk-0");

Comment 7

[Brian Yuan]

A very simple question, can Mozilla/NSCP6.x use a locale or charset (not
language) specific configuration file so that we can specify
user_pref("font.name.*") for different locale/charset? That will fix most of the
current showstoppers in Asian languages support.

Comment 8

[Masaki Katakai]

Brian@Sun,

You're seeing bug 66744 when you use gb2312 fonts for zh-CN as I mentioned.
We, Sun (distributor of Mozilla) can choose the default setting.
That was my question. How is the result when you use gbk-0 fonts?
Actually, zh_CN.EUC locale of Solaris does not have gbk-9 fonts, so
the glyphs may not become beautiful. Please see my comments of
the bug report.

For GB18030, if you could not find in bugzilla about the issue,
how about filing separate bug?

Comment 9

[Brian Yuan]

No, you misunderstand my question, what we need is to use different fonts for 
different locales: gb2312 fonts for zh_CN.EUC and gbk fonts for zh_CN.GBK and 
zh_CN.UTF-8, not to use either of them in all of the zh_CN.* locales. I heard 
that NSCP6.0 was language sensitive, not locale sensitive, right?

Comment 10

[Erik van der Poel]

>If the page is unicode (ie: does not have a langGroup) use the langGroup of the 
>primary font. The primary font's langGroup is a strong hint from the user as to 
>which langGroup they prefer.

When the charset is a Unicode-based one (e.g. UTF-8), then Mozilla falls back
to the locale. See nsLanguageAtomService.cpp:

http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsLanguageAtomService.cp
p#229

Comment 11

[Masaki Katakai]

Hi Brian, my last comments were not for your question of 2001-02-26.

I understand we're not able to specify the font setting per locale.
The setting is provided per language.

Comment 12

[Erik van der Poel]

Mozilla does not currently support locale-charset-specific default fonts. It
just has one default font for each language group/generic font:

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js

Comment 13

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 14

[Brian Yuan]

Per Brian@Netscape's request, I am listing the problems and requirements in
Mozilla for the two Chinese languages:

1. Problem --- Simplified Chinese: Japanese fonts are used in Menu items
   Requirement --- Use gb2312 fonts
2. Problem --- Traditional Chinese: Japanese fonts and Simplified Chinese fonts
are used in Menu
   Requirement --- Use BIG5 fonts
3. Problem --- Simplified Chinese: cannot display some native GBK characters
   Requirement --- Use gb2312 fonts as default, gbk fonts as fallback
4. Problem --- Traditional Chinese: cannot display some native BIG5 characters
   Requirement --- Use BIG5 fonts as default
5. Problem --- Traditional Chinese: cannot display native CNS11643-2 Characters
   Requirement --- Use both CNS11643-1 and CNS11643-2 fonts

Thanks.
Brian@Sun
6. Problem --- Simplified Chinese, cannot display some UTF-8 encoded Chinese
Characters
   Requirement --- Use GB2312 fonts as default, use gbk fonts as fallback.
7. Problem --- Traditional Chinese, cannot display some UTF-8 encoded Chinese
Characters
   Requirement --- Use BIG5 fonts as default, use gbk fonts as fallback.

Comment 15

[Masaki Katakai]

I've started debugging around the codes of gfx/gtk.

Comment 16

[Linda Baliman]

P1 bug for Sun;  setting Priority = P1;  adding intl, nsbeta1 keywords

Comment 17

[kill this account]

please see the patch in bug 67732

Comment 18

[kill this account]

fix checked in as part of the checkin for bug 67732

Comment 19

[kill this account]

byuan: can you describe how to QA this?

Comment 20

[Teruko Kobayashi]

Changed QA contact to [e-mail] for now.

Comment 21

[Masaki Katakai]

To verify this:

1. remove font path for gb2312.1980-0
2. set gb2312 fonts for zh-CN
3. add font path for gbk-0 and other asian fonts
4. export NS_FONT_DEBUG=1
4. try to browse gb1213 characters page on Mozilla

gbk-0 fonts should be used as top priority by this fix.
Without fix, jis and cns fonts are used.

I've personally verified on my environment.

Comment 22

[Yuying Long]

Mark as verified since it wroks fine on 09-04 trunk build.