121520 - Mail headers or bookmarks are not displayed with the fonts specified for the corresponding language

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[ji]

Build: 01/23 linux trunk build

When mozilla is started in Japanese locale, subjects and senders of gb2312 mails
are not displayed in Chinese fonts. The glyphs are in difference size and
different style. This problem doesn't exist when mozilla is started in C locale.

Steps to reproduce:
1. Launch Mozilla in Japanese locale. Confirm from preference window that
Chinese fonts are used for Chinese display.
2. Launch Mail.
3. Select a gb2312 mail, observe the header display on the thread and envelope.
Chinese characters are displayed  in different font size and different styles. 
Screenshot to follow.

Comment 1

[ji]

Attachment: A screenshot

Comment 2

[ji]

It's a regression from 6.2.1. I can reproduce the problem on 12/05 build.

Comment 3

[ji]

Same problem in Bookmark. 
On 6.2.1, at least the sizes of glyphs are same though some chars are in bold
and some are not. Now it's worse.

Comment 4

[ji]

Changed the component and reassigned to shanjian per Naoki's suggestion.

Comment 5

[Yuying Long]

For those Simp. Chinese characters which are displayed in bigger or maybe like
bold font face, you can find that they have different glyph than Japanese, in
another word, you can not find them in Japanese kanji characters.  
For those Simp. Chinese characters who has the same glyph as in Japanese kanji,
will be displayed same as in Japanese (smaller). 

If you go any Simp. Chinese page, all the characters will be displayed as bigger
and a "bold" face look.  And we can not change it unless we use Brian's AABS
modification in unix.js.

Btw, the problem in this bug on bookmark seems not regression from N6.2.1 for me.

Comment 6

[Yuying Long]

Xianglan and I discussed and did more test on both latest trunk build and N6.2.1
build:

1. The problem here is: with Japanese locale, even for Simp. Characters, it will
still using Japanese font first, for those characters that not in Japanese, then
will pick up Simp. Chinese font for them.  That explained why we saw different
font face in one Chinese string.

2. It's not a regression, the reason that we saw the Chinese characters more
ugly (big and small mixed together) than in N6.2.1 is because now we are using
AABS so that those characters in Japanese font face became smaller and Simp.
Chinese font still not change.

Comment 7

[ji]

It seems this problem only exists on one-line text widget, like mail subject,
bookmarks, Tasks.... It doesn't exist on a multiple-line text area, like mail body.

Comment 8

[Yuying Long]

Attachment: a screen shot for Japanese/Chinese personal toolbar names with zh_CN locale

You will find, when locale=zh_CN, then the Simp. Chinese characters will
displayed as chinese font, but then Japanese characters will not be displayed
as properly font.

I'm using linux RedHat7.1-JA.

Comment 9

[Shanjian Li]

I saw the problem on my Linux. We did not honor charset contained within 
mime partII encoded string. This is true for all platforms, not only Linux.
It is just not noticable on windows (or yet?). This problem will be a little
bit hard to fix.

naoki,
Mozilla seems converting the whole email (header, body) to utf8 encoding before 
further processing (display, etc.). We need to find a way to reserve language
information during this converting. 

Comment 10

[nhottanscp]

There is a bug 102623 to put language for mail body. But I don't think no bug
filed for headers.

Comment 11

[nhottanscp]

I mean no bug for headers. I think that would be only possilbe for envelop
display. For the list, I don't think we can put languages per list item.

Comment 12

[Shanjian Li]

I am not quite sure how the subjest list is displayed. Did we compose a html doc, or 
a xul doc? If it is html, we need to somehow reserve this language info and put it 
into hmtl doc. XUL language processing is incomplete. If it is xul, we may have to 
wait for that to be fixed first. 

reassign to naoki.

Comment 13

[ji]

Yes, this problem exists on Windows too. Changed the platform to ALL.
It doesn't seem to be using the fonts specified for default locale either. For
example, I'm on US W2K with default locale set to Japanese. I specified MS
Gothic font of size 24 for Japanese from preferences. But I see that the
Japanese fonts used to display Chinese mail subject is size 12. 

Comment 14

[ji]

Attachment: A screenshot on US W2K with default locale set to Japanese. The selected mail is a gb2312 mail.

Comment 15

[ji]

A generic problem for all the languages, changed the summary accordingly.
Nominating for nsbeta1, it looks pretty ugly for mail headers, bookmarks, tasks,
location bar history display.

Comment 16

[ji]

Per Naoki's request, filed bug 124510 seperately for mail header display problem
on envelope.

Comment 17

[nhottanscp]

This is a generic font/language handling, reassign to shanjian.

Comment 18

[ji]

Attachment: A Japanese mail display on thread pane on a Simplified Chinese XP system.

Comment 19

[Shanjian Li]

If the font system has been told about language group, the display should be OK.
So this bug is blocked by 124510. I didn't see much chance for 124510 to be
fixed in 1.0 time frame. 

Comment 20

[ji]

Bug 125410 is for bookmarks. How about mail thread pane, tasks, and url location
bar history? I wonder for the list display, if we don't have language info for
each item on the list, is it possible to use unicode fonts or the fonts that has
most glyphs? In that case we can have consistent look for most items on the
list. If the system doesn't have those fonts, we can fallback to system default
fonts. 

Comment 21

[Frank Tang]

nsbeta1- 

Comment 22

[ji]

*** Bug 126550 has been marked as a duplicate of this bug. ***

Comment 23

[Shanjian Li]

This bug can't be resolved in near future. 

Comment 24

[Jungshik Shin]

This bug needs some help from mailnews maintainers. The key issue is how the
message list pane is constructed (html or xul). For both,  we have
'lang'/xml:lang based font selection mechanism in place. As mentioned in comment
#9, we need to preserve either charset information (specified in RFC 2047
header) or lang inferred from the MIME charset and specify that with
lang/xml:lang so that the layout/gfx can  refer to it to pick up a font
appropriate for 'lang/xml:lang'. 
 

Comment 25

[Frank Tang]

shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first. 

Comment 26

[Jungshik Shin]

ftang, why are you marking a bunch of *valid* bugs as 'wontfix'? 'Wontfix' is
not the same as there being no appropriate owner. 

You're making it harder to keep track of important I18N bugs