Closed Bug 75706 Opened 23 years ago Closed 23 years ago

Some GBK characters can not be displayed correctly in Solaris Trunk

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: eyan, Assigned: ftang)

Details

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

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
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
reassign to ftang and target moz9.1
Assignee: nhotta → ftang
Target Milestone: --- → mozilla0.9.1
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Add Brian@Netscape in Cc
QA Contact: andreasb → ylong
Ftang - Is this important for nsbeta1? Is this a requirement from the Sun team? 
Please Advise . . .

Adding Lbaliman to cc: list.
Sun says this is not a show-stopper
Keywords: intl
Good, then we do not need this one for nsbeta1. Let's minus it for beta, and
assign a milestone after M0.9.1
Changed QA contact to katakai@japan.sun.com
QA Contact: ylong → katakai
The ucvcn is pretty massy right now. I clean up it to fix bug 75928. Hope that 
will also fix this one. 

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

Assign Ervin to QA contact
QA Contact: katakai → eyan
Whiteboard: depend on 80772 expect date 5/17
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
Closed: 23 years ago
Resolution: --- → FIXED
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)
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 '?'

Ervin,

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

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.