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

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?

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.

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.

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 "-->"?

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.

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.

erik, ftang, need r= and sr=

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?

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.)

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.

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

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?

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.

set mile stone

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.

change summary to better describe the problem.

>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.

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

fix checked in.

Fixed verified on 03-27 Win32 Mtrunk build.