200084 - gbk1988.1989-0 is defined as GBK, but us-ascii

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Masaki Katakai]

In gfx/src/gtk/nsFontMetricsGTK.cpp,

"gbk1988.1989-0" is defined as GBK, but it should be us-ascii.

-  { "gbk1988.1989-0",     &FLG_ZHCN,    &GBK           },

Because of this bug, in GBK locale, UI strings are displayed
as garbage on Mozilla GTK2 build.

Comment 1

[Masaki Katakai]

Attachment: patch

proposed patch, defined USASCII with "us-ascii" and set this
to gbk1988.1989-0.

Comment 2

[Masaki Katakai]

Comment on attachment 119045 [details] [diff] [review]
patch

Brian, could you review please?

Comment 3

[kill this account]

I'm unclear if there is a converter issue here?

Frank: would you kindly take a look at this?

Comment 4

[Frank Tang]

are you sure? take a look at bug 82793
I think I add that line because we see the font from Sun use that name for GBK. 
I cannot remember which particular font we saw but I am sure I add that line for
that particular reason. Can you talk to those people in Sun China localization
team ?

Comment 5

[Ervin Yan]

"gbk1988.1989-0" is a Chinese national standard character set which is equal to
American ASCII character set. 

On solaris, "gbk1988.1989-0" is just an alternative font for us-ascii charset.
so it should not be defined as a GBK font in Mozilla. 

Comment 6

[Roland Mainz]

Ervin Yan wrote:
> On solaris, "gbk1988.1989-0" is just an alternative font for us-ascii charset.
> so it should not be defined as a GBK font in Mozilla

... but shouldn't it be preferred to use the ASCII glyphs from "gbk1988.1989-0"
fonts over ASCII glyphs from a latin1-like font in chinese text ?

Comment 7

[Brian Yuan]

Frank,
In Solaris, gbk1988.1989-0 is an ASCII font used in zh.GBK locale, it doesn't
contain any GBK characters that are all double-byte,  the fonts for all of the
GBK characters are gbk-0.

Comment 8

[Masaki Katakai]

Comment on attachment 119045 [details] [diff] [review]
patch

Frank, could you review please?

Comment 9

[Masaki Katakai]

'big5-0' is also usascii.

Comment 10

[Masaki Katakai]

Attachment: include big5-0

big5-0 is also defined as usascii.

Comment 11

[Masaki Katakai]

Comment on attachment 121169 [details] [diff] [review]
include big5-0

Frank, could you review please?

Comment 12

[Ervin Yan]

Masaki: on Solaris, big5-0 is usascii font, big-1 is true BIG5 font.

but on Linux, big5-0 is true BIG5 font, and no big5-1 font.

so your new patch maybe have some problems on Linux.

Comment 13

[Masaki Katakai]

Thanks, Ervin.

Let's fix only gbk1988.1989-0 issue here.

Comment 14

[Masaki Katakai]

Comment on attachment 121169 [details] [diff] [review]
include big5-0

rbs, could you sr= please?

Comment 15

[rbs]

Comment on attachment 119045 [details] [diff] [review]
patch

rs=rbs

rubber-stamping based what you guys said (particularly comment 5 and comment
12).

Comment 16

[Masaki Katakai]

Comment on attachment 119045 [details] [diff] [review]
patch

I understand the risk by the change is low, I have added a new entry with the
same maner.

It will help Solaris GBK users.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 119045 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.4b

Comment 18

[Roland Mainz]

Attachment: Xlib gfx version of attachment 19045

Same change as attachment 19045 [details] [diff] [review] (which is for gfx/src/gtk/) for gfx/src/xlib
...

Comment 19

[Roland Mainz]

Comment on attachment 121730 [details] [diff] [review]
Xlib gfx version of attachment 19045 [details] [diff] [review]

Requesting r=/sr=/a= (this is the same change as the gfx/src/gtk/ patch) ...

Comment 20

[Simon Montagu :smontagu]

Comment on attachment 121730 [details] [diff] [review]
Xlib gfx version of attachment 19045 [details] [diff] [review]

r=smontagu. Why can't more of nsFontMetricsXlib.cpp and nsFontMetricsGTK.cpp be
in a common file?

Comment 21

[Roland Mainz]

Simon Montagu wrote:
> Why can't more of nsFontMetricsXlib.cpp and nsFontMetricsGTK.cpp be
> in a common file?

Remember that I added support for multiple physical device instances in
gfx/src/xlib ? If we port that change to gfx/src/gtk we can start merging both
codelines after that... :)

Comment 22

[Simon Montagu :smontagu]

Even without thinking about merging the code we could merge all the static data
which both source files have in common, no?

Comment 23

[Roland Mainz]

Simon Montagu wrote:
> Even without thinking about merging the code we could merge all the static 
> data which both source files have in common, no?

I would not recommend that for now since this usually calls for trouble with
StaticBuilds (structure names _must_ be different otherwise we break
staticbuilds). It is technically possible to do it but I would not recommend it
- that causes unneccesary trouble and is just an useless extra step on the way
to finally merge both codelines in gfx/src/x11shared/ ...

Comment 24

[Simon Montagu :smontagu]

>(structure names _must_ be different otherwise we break staticbuilds)

That problem could be solved with macros, but we should probably take this whole
discussion somewhere else :-)

Comment 25

[Roland Mainz]

Simon Montagu wrote:
> > (structure names _must_ be different otherwise we break staticbuilds)
>
> That problem could be solved with macros,

or we could use |template| stuff or other fun.

> but we should probably take this whole discussion somewhere else :-)

Or just stop the discussion about such intermediate steps. We're likely merging
lots of code from gfx/src/gtk and gfx/src/xlib into gfx/src/x11shared/ - but
discussing now some "nice-looking" extra steps may result in painfull bugzilla
RFEs which only make the way to the final goal longer... much longer... ;-(

Comment 26

[Masaki Katakai]

will check in both when we get a= for 1.4b.

Comment 27

[(not reading, please use [e-mail] instead)]

Comment on attachment 121730 [details] [diff] [review]
Xlib gfx version of attachment 19045 [details] [diff] [review]

a=sspitzer

Comment 28

[Masaki Katakai]

Thank you all.

checked into 1.4b.