72125 - default font for simplified chinese system does not work

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Shanjian Li]

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (WinNT; U)
BuildID:    

Hi,
         When opening a Simplified Chinese page (charset = GB2312) in Mozilla
    I notice that a system default font is used rather than one specified in a
    style sheet.  In addition, when I try to print any GB2312 pages, all
    characters are question marks.  Is this bug already known?  I have searched
    in bugzilla and can't seem to find anything related.  To reproduce browse to
    http://cn.yahoo.com/ on a Simplified Chinese Windows system.  You will
    notice the font is a default font and is applied to all characters.  If you
    browse to this same page on an English Windows OS (that has the proper
    character set installed), you will notice the page is displayed correctly.
    In addition, the page prints "?" on a chs system but prints the correct
    characters on an English system.  This defect has manifested itself as quite
    a big deal for our company.  Can anyone help me?

Reproducible: Always

Comment 1

[Shanjian Li]

I finally made my simplified chinese system running and reproduce the problem. 

Some initial investigation showed that mozilla did not handle the font family 
property in css well. I am not sure if this is because we are doing some kind 
of normalization when parsing font family properties. In original CSS document,
"MS Song, ËÎÌå(in Chinese), Beijing" are specified, and in style structure, 
only "serif" can be found.  In nsFontMetricsWin.cpp, 2900, 
    gPref->CopyCharPref(name, &value);
maps "serif" to "MS Song", but in simplified chinese system the font name is
"ËÎÌå(in Chinese)". That's why we are experiencing difference between chinese
and english systems.

That at least reveals 2 problem and one suspection.
1, "Serif" should be mapped to "ËÎÌå(in Chinese)" in simplified chinese system. 
  We might have similar problem on other native system. 
2, CSS parsing does handle fontfamily name well.
3, (Suspection) We seems unable to handle fontfamily name list.

Erik, could you offer some comment?

Comment 2

[Erik van der Poel]

We probably need to change the Chinese default fonts to their localized
(Chinese) names in the following file:

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

See Kat's comments in the newsgroup about the style sheet being sent with a
Content-Type of "text/html". It should be "text/css". If this works in MSIE,
then we may need to consider making it work in Mozilla too. You can view the
Content-Type using the following tool:

  http://webtools.mozilla.org/web-sniffer/

Insert the following URL into the above tool:

  http://cn.yahoo.com/

and follow the link to the style sheet. You will see the "text/html"
Content-Type, even though the referrer said "text/css". This may be confusing
Mozilla.

Comment 3

[Shanjian Li]

erik,
We can use chinese name to replace "MS Song" in winpref.js, but that will cause problem 
in non-SChinese system. Same thing will happen to Japanese, Korean name. When looking 
for generic font for certain language group, should we try a list of name instead of one?

I did notice that the css file is named gbcss.html, which is a little confusing. But after 
I download everything to local and rename gbcss.html to be gbcss.css, the same thing still 
happened. I am still suspecting that mozilla did not handle font family list right.

Comment 4

[Erik van der Poel]

Yes, I also thought about supporting a list of fonts in the default font prefs.
However, we must not forget to consider the font prefs UI when making such a
change.

When you changed gbcss.html to gbcss.css, did you also remove the HTML comment
markers "<!--" and "-->"?

Comment 5

[Shanjian Li]

Attachment: css files used by cn.yahoo.com

Comment 6

[Shanjian Li]

Attachment: minimum test page

Comment 7

[Shanjian Li]

I attached the 2 files for your reference.

After I set default font to be "songti" (in chinese), the text size does get 
smaller. That means css is read correctly, but font family does not work.

I suggest that we still keep one font as default and this one is configurable 
through preference. But we add a default backup list. In case the default is 
not found, we will traverse the backup list and use the first one available as
default. We can update default as well since the one there is not available.
This way no UI change involved.

Comment 8

[Shanjian Li]

While I was working on this bug, I found more than one problem. 
bug 72657 is filed to handle system font name problem for CJK 
windows. 

The reason while the encoded chinese named font in css can not be 
used was because mozilla does not handling CSS's encoding. That should 
be a major proble. I file 72568 for this problem, while kept this one 
to handle default font problem.

Comment 9

[Shanjian Li]

Attachment: patch part 1, traverse fallback list in default pref

Comment 10

[Shanjian Li]

Attachment: patch part 2, add fallback list font for CJK

Comment 11

[Shanjian Li]

erik, ftang, need r= and sr=

Comment 12

[Frank Tang]

erik:
shanjian wrote:
>I am still suspecting that mozilla did not handle font family list right.
erik wrote:
>Yes, I also thought about supporting a list of fonts in the default font prefs.

I think shanjian mean the "font family list" inside the CSS, not the one inside
pref.

Your approach seems interesting. Erik- what do you think? But does that resolve
this issue?

Comment 13

[Erik van der Poel]

Frank: No, Shanjian was referring to the fonts in the default pref files.

Shanjian: Yes, that is one of several ways to solve this problem, but the font
prefs dialog will not pick up the .1, .2, etc fonts unless you change that code
too. (When the user starts up Mozilla for the first time, there are no user
prefs yet, so we use the default prefs. These fonts ought to get reflected
accurately in the font prefs UI.)

Comment 14

[Shanjian Li]

erik,

That's why I keep the default one and add *.1, *.2 .. as fall back. This way no 
UI change is involved. Fallback ones will not be used if default exist, and 
users are not allowed to change it (or even see it in this case).

The time when we first set user pref from default pref, do we check the availability
of font? If the work was done in cpp instead js, we can traverse the list and copy
the first available font from list, that will make it better.

Comment 15

[Erik van der Poel]

Shanjian, I think it would be nice if the user could see what font would be
used when they open the font prefs dialog (without changing anything). I believe
the font prefs UI is implemented in JS:

  xpfe/components/prefwindow/resources/content/pref-fonts.js

Comment 16

[Shanjian Li]

erik,
I will open a new bug to take care of displaying fallback default fonts.
For the time being, fallback fonts are just name variation. Let's check in
this patch and fix the problem first. What do you think?

Comment 17

[Erik van der Poel]

The "name" buffer has a fixed size. You need to check the size before writing
the new null terminator, '.' and '1'.

In the default prefs file, the ASCII names don't need the comment at the end
of the line (since those names are already in the string). Also, some of the
non-ASCII strings are missing the ASCII comment at the end of the line.

Please create a new bug report for the JS code in the font prefs dialog.

If you do all of the above, I can give my sr.

Comment 18

[Shanjian Li]

set mile stone

Comment 19

[Shanjian Li]

erik,

Yes, the name buffer has fixed size of 128. But since the preference name is 
not set by user, and we know it is long enough, I do not think there is any 
need to check the size.

Comment 20

[Shanjian Li]

change summary to better describe the problem.

Comment 21

[Shanjian Li]

Attachment: revised part2 fix.

Comment 22

[Frank Tang]

>Yes, the name buffer has fixed size of 128. But since the preference name is
>not set by user, and we know it is long enough, I do not think there is any
>need to check the size.

I agree with shanjian. The possible value of name is limited by our C++ code but
not the value in the pref. Therefore, we can sure the size is enough in this
particulare fix.

Comment 23

[Shanjian Li]

Bug 73510 has been filed to handle fallback font display in preference dialog box.

Comment 24

[Shanjian Li]

fix checked in.

Comment 25

[Yuying Long]

Fixed verified on 03-27 Win32 Mtrunk build.