299621 - Mac displayed some CJK characters as blank (missing characters)

Status: RESOLVED INCOMPLETE

(Core :: Internationalization, defect)

Description

[Hung-Te Lin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: 

When using a Mac with Chinese or Japanese UI, Gecko engines sometimes display
CJK characters as blank (This happens on both Gecko program UI <menus, buttons>
and the web content it displayed). After some experiements, we realized that 
it is related to fonts and can be solved by overriding UI fonts in userChrome.css
or intl.css, like

* { font-family: "Lucaida Grande",serif; } or
* { font-family: "Apple LiGothic Medium",serif; } 
(LiGothic is default font for Traditional Chinese)

However it's also related to system font cache so every Macs may
have different characters "missing". Some people may even never get this
problem.

We saw in Japanese language packs for Mac they also have 
* { font-family: "Lucaida Grande",serif; } 
settings in global/intl.css, so maybe they also got this issue before?

If we remove these settings from ja-JP.jar, a Japanese Firefox
running on Mac OSX may also get missing characters (for a system
that does have missing characters problem for other locales, like zh-TW)

Reproducible: Sometimes

Steps to Reproduce:
1. Run localized build of Firefox/Thunderbird (for example, zh-TW) on Mac
Actual Results:  
Some UI entries may have missing characters.
For Thunderbird, many people have missing characters on the localized
"Addressbook".

Expected Results:  
If we use userChrome.css or intl.css to set font,
everything appears.

We tried to set font-size: 36px; in userChrome.css to observe which font is
really used by MacOSX and it seems like that it did not use system default font.
On a Traditional Chinese MacOSX with Apple LiGothic Medium as default,
system used STHeiti for UI default.
And it we override the font by userChrome.css or intl.css, it worked fine.

Comment 1

[Hiro]

In trunk L10N build(ja-JP-mac), intl.css has changed as follows.

* {
  font-family: "Lucida Grande", "ヒラギノ角ゴ Pro W3", sans-serif;
}

test build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk-l10n/firefox-1.0+.ja-JP-mac.mac.dmg

Comment 2

[Hiro]

The same change as commnet#1 is scheduled to be done about Thunderbird. 
And in a Japanese environment, when this setting is removed, UI becomes ugly. 

Comment 3

[Hung-Te Lin]

After more deeper investigation, we believe changing fonts is just a hack and
may not always work. As you work with Firefox (with the chosen font) longer,
the font cache has more chance to be messed. So after a long period of daily
use the problem occurs again.

The root cause of this issue should be QuickDraw. A user in Taiwan tried to
use CoreGraphics and ATSUI to rewrite and it seems like working perfectly even
after a long time.
Ref: http://jclin.blogspot.com/2005/10/atsui-gfx-preview.html
(Chinese web page, sorry).

We believe that this issue will be fixed when Mozilla has changed to gfx2.
Right now there is no good solution for this issue.

Comment 4

[Frank Woolf]

I have this problem with Firefox 1.5.0.7 on a MacBook Pro running OS 10.4.8 (and earlier).

I can get Traditional and Simplified Chinese characters to work almost every where on pages by ensuring that the DB and the pages are all set to UTF-8.

The only areas I have found impossible to fix is in Drop down menus that are populated from a database, in buttons, and in fields where users enter data such as forums and classified adds.  

The problem with the drop down menus and buttons seems to exist only in Mac Firefox and looks OK in every other browser I have tried.  

The problem with user entered characters in forums and classifieds being garbled seems to be reproducable in other browsers including Safari.

All other Chinese characters on pages that are either hard coded or contained in PHP variables (most) seem to be OK.

Comment 5

[Jungshik Shin]

Perhaps, it's not good idea to make this bug depend on bug 121540 because the patch there will never see the light. Instead, thebe-enabled trunk build will fix this and many other related problems. 

Anyway, Frank, you may wanna try Makoto's build mentioned in bug 121540 comment #267. 

Comment 6

[Frank Woolf]

(In reply to comment #5)
> Perhaps, it's not good idea to make this bug depend on bug 121540 because the
> patch there will never see the light. Instead, thebe-enabled trunk build will
> fix this and many other related problems. 
> 
> Anyway, Frank, you may wanna try Makoto's build mentioned in bug 121540 comment
> #267. 
> 
Thanks but my main concern is visitors to the web site so its better I see what they see without using a different build.

Comment 7

[Wayne Mery (:wsmwk)]

do you see this problem with FF2?

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #7)
> do you see this problem with FF2?
> 

No response for ~4 months, 1.5.0.x has been end-of-life-ed, resolving incomplete.