Some GBK characters can not be displayed correctly in Solaris Trunk

RESOLVED FIXED in mozilla0.9.1

Status

()

Core
Internationalization
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: Ervin Yan, Assigned: Frank Tang)

Tracking

({intl})

Trunk
mozilla0.9.1
Sun
Solaris
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: depend on 80772 expect date 5/17)

(Reporter)

Description

17 years ago
I verified the diplay of GBK characters in Solaris Trunk, and I find some
problems:

All the GBK characters display OK, except:
0xa2a1 --> 0xa2aa displayed as NULL
0xa6e0 --> 0xa6f5 displayed as NULL
0xa8a2 --> 0xa8c0 displayed as NULL
0xa989 --> 0xa995 displayed as '?'

and in zh.GBK locale, the size of the characters are not the same.
but in zh.UTF-8 locale, the size is the same.

see also:
http://bugzilla.mozilla.org/show_bug.cgi?id=60826

Comment 1

17 years ago
Katakai san, can you reproduce this?
Summary: Some GBK characters can not be displayed correctly in Solaris Trunk → Some GBK characters can not be displayed correctly in Solaris Trunk
(Assignee)

Comment 2

17 years ago
reassign to ftang and target moz9.1
Assignee: nhotta → ftang
Target Milestone: --- → mozilla0.9.1
(Assignee)

Updated

17 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 3

17 years ago
Add Brian@Netscape in Cc

Updated

17 years ago
QA Contact: andreasb → ylong

Comment 4

17 years ago
Ftang - Is this important for nsbeta1? Is this a requirement from the Sun team? 
Please Advise . . .

Adding Lbaliman to cc: list.

Comment 5

17 years ago
Sun says this is not a show-stopper

Updated

17 years ago
Keywords: intl

Comment 6

17 years ago
Good, then we do not need this one for nsbeta1. Let's minus it for beta, and
assign a milestone after M0.9.1

Comment 7

17 years ago
Changed QA contact to katakai@japan.sun.com
QA Contact: ylong → katakai
(Assignee)

Comment 8

17 years ago
The ucvcn is pretty massy right now. I clean up it to fix bug 75928. Hope that 
will also fix this one. 
(Assignee)

Comment 9

17 years ago
This could be caused by the buggy ucvcn converters. wait and see what happen 
after we land 75928

Comment 10

17 years ago
Assign Ervin to QA contact
QA Contact: katakai → eyan
(Assignee)

Updated

17 years ago
Whiteboard: depend on 80772 expect date 5/17
(Assignee)

Comment 11

17 years ago
It should be fixed, right now. reopen if you still see the same problem. IF you 
see different problem- please file new bug. recycle bug report will confuse 
people
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

17 years ago
Verified in Mozilla nightly build 2001052210:
0xa2a1 --> 0xa2aa displayed OK.
0xa6e0 --> 0xa6f5 displayed OK.
0xa8a2 --> 0xa8c0 displayed OK.

but still some problems exsist.
0xa989 --> 0xa995 displayed as '?' (exist in old build)
0xa8bc and 0xa8bf displayed as '?' (new in latest build)
0xfe50 --> 0xfea0 displayed as '?' (new in latest build)
(Reporter)

Comment 13

17 years ago
Verified in Mozilla 2001061410 on Solaris:

in zh_CN.GB18030 locale, all OK. 

But in zh_CN.GBK locale:
0xa8bc and 0xa8bf displayed as '?'
0xa989 --> 0xa995 displayed as '?'
0xfe50 --> 0xfea0 displayed as '?'

Comment 14

17 years ago
Ervin,

The solaris locale is not important for Mozilla folks. What are your
font setting on Mozilla? which fonts are available on your environment?
(Reporter)

Comment 15

17 years ago
I use gbk-0 font for zh-CN environment in my Solaris machine.
You need to log in before you can comment on or make changes to this bug.