Closed
Bug 129188
Opened 23 years ago
Closed 23 years ago
[Mac OS X]The western font looks ugly when locale set to Chinese or Korean
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: amyy, Assigned: ftang)
Details
(Keywords: intl)
Attachments
(3 files, 3 obsolete files)
Build: 03-05 build
When setting the system locale to Chinese (both SC and TC) or Korean, the
western font looks ugly, the whole UI for the application doesn't look good.
Screen shots for Japanese and TradChinese locale will be followed, you will see
the western fonts with Japanese locale are looks fine, but the other one is not
good, and they are using same fonts.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Comment 3•23 years ago
|
||
On same locale setting with IE5.1-US, the western fonts are displayed fine, also
seems it looks OK with textEdit.
-> nsbeta1.
Assignee | ||
Comment 5•23 years ago
|
||
nsbeta1+ , give to ftang
Assignee | ||
Comment 6•23 years ago
|
||
assign
Assignee | ||
Comment 7•23 years ago
|
||
It may caused by the following code
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#322
242 NS_IMETHODIMP nsDeviceContextMac :: GetSystemFont(nsSystemFontID aID, nsFont
*aFont) const
319 Str255 fontName;
320 SInt16 fontSize;
321 Style fontStyle;
322 ::GetThemeFont(fontID, smSystemScript, fontName, &fontSize, &fontStyle);
323 fontName[fontName[0]+1] = 0;
324 aFont->name.AssignWithConversion( (char*)&fontName[1] );
also
336 aFont->name.Assign(NS_LITERAL_STRING("geneva"));
the code looks like it assume the fontName is in ASCII but we all know it is not
always true.
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•23 years ago
|
||
ok,what happen is this, the nsDeviceContextMac :: GetSystemFont
will ask the apperance manager to return a font for the system script. Somehow
the Trad Chinese return a very bad looking one.
work around is always ask the Roman script one.
Assignee | ||
Comment 9•23 years ago
|
||
Assignee | ||
Comment 10•23 years ago
|
||
nhotta said this is not good enough, he said if the Chinese one is bad then we
should fix only the chinese one.
Assignee | ||
Comment 11•23 years ago
|
||
the problem is I see two issue here.
1. the Japanese one GetThemeFont return are corrupted by the
AssignWithConversion method (instead of convert Shift_JIS to Unicode), and
therefore the Japanese theme font may not be used at all. (and that is why it
does not show the ugly looking glyph)
2. the quality of ASCII text is very bad with Chinese and Korean themem font.
Assignee | ||
Comment 12•23 years ago
|
||
The reason the Japanese looks ok is because
aFont->name.AssignWithConversion( (char*)&fontName[1] );
damange the Japanese font name and therefore it does not use Japanese font. Once
we fix that part, the problem also show up in Japanese.So. I still suggest we
use the smRoman font.
Assignee | ||
Comment 13•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #73332 -
Attachment is obsolete: true
Assignee | ||
Comment 14•23 years ago
|
||
this patch fix two issue.
1. the 2nd part convert the font name correctly into unicode
2. the 1st part force to use smRoman since we know the ASCII part in other
script code render ugly.
Comment 15•23 years ago
|
||
Comment on attachment 73547 [details] [diff] [review]
v2 of the patch
* fix the tab
* '\0' - cast to PRUnichar
* Only use smRoman for the scripts which we have the problem, Korean,
Simplified Chinese, Traditional Chinese but not for Japanese.
+ ::GetThemeFont(fontID, smRoman, fontName, &fontSize, &fontStyle);
Attachment #73547 -
Flags: needs-work+
Assignee | ||
Comment 16•23 years ago
|
||
fixed and checkin
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•23 years ago
|
||
sorry, close the wrong bug, reopen
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 18•23 years ago
|
||
Attachment #73547 -
Attachment is obsolete: true
Comment 19•23 years ago
|
||
Comment on attachment 73608 [details] [diff] [review]
patch v3
+ aFont->name.AssignWithConversion( (char*)&fontName[1] );
This also exists in the original code but it has to pass a length fontName[0].
Please put a comment for the reason of assigning smRoman for smKorean,
smTradChinese and smSimpChinese.
Attachment #73608 -
Flags: needs-work+
Comment 20•23 years ago
|
||
Address nhotta's comments, and sr=sfraser
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Assignee | ||
Comment 21•23 years ago
|
||
Attachment #73608 -
Attachment is obsolete: true
Comment 22•23 years ago
|
||
Comment on attachment 74165 [details] [diff] [review]
patch v4 adderss nhotta's comment
r=nhotta
Attachment #74165 -
Flags: review+
Comment 23•23 years ago
|
||
Comment on attachment 74165 [details] [diff] [review]
patch v4 adderss nhotta's comment
a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74165 -
Flags: approval+
Assignee | ||
Comment 24•23 years ago
|
||
fixed and check into trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 25•23 years ago
|
||
Belated sr comment: we need to factor that TEC converter stuff into a single
place in gfx. We have that 20-odd lines of code in several places.
Reporter | ||
Comment 26•23 years ago
|
||
Fixed verified on 03-18 trunk build/Mac 10.1.3.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•