57462 - 0x5c should be displayed as yen sign

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Koike Kazuhiko]

0x5c in Shift-JIS html file is displayed as small point.

Without charset specification, it is displayed as backslash.

But it should be displayed as yen sign.

This problem is observed on Win95 and Win98. On Win2000 it's displayed
correctly.

Comment 1

[Koike Kazuhiko]

Attachment: Testcase(Shift-JIS)

Comment 2

[Koike Kazuhiko]

Attachment: Testcase(no charset specification)

Comment 3

[Koike Kazuhiko]

See 92(0x5c) cell in the attached table.

Comment 4

[nhottanscp]

Reassign to erik.

Comment 5

[Teruko Kobayashi]

Related bug is 4238.  I can see the problem on Win98J and Win95J.
Even though same yen sign, some page is displayed correctly on Win98J and Win95J.

I am investigating. 

Comment 6

[Koike Kazuhiko]

It may be correct to display 0x5c without charset as backslash.

<span lang="en">0x5c</span> is displayed as backslash and lang="jp"
is displayed as yen sign. It seems a correct behaviour.

Comment 7

[Teruko Kobayashi]

I have a test case in http://babel/tests/browser/kinsoku/sjis1/test1_sjis.html
#3, yen sign is displayed correctly on Win98J and Win95J.  
I do not know why. I used this page to verify the bug 4238.

I create new page including yen sign.  I can see it as "・".  
This does not happen on Winnt4.0J and Windows 2000J.

I thought because the attached testcase was used table, table causes the problem.
But, I found out I could reproduce this without table.
 

Comment 8

[Teruko Kobayashi]

When I type "0x52" by Shift_JIS character coding in Composer, Yen sign is displayed
correctly.  Then, after you save the page as locale drive, the yen sign is not displayed
correctly if you look at the page from Navigator on Win95J and Win98J.

Comment 9

[Erik van der Poel]

Teruko and I tried another test on her Win9x-J machine. When you have a Yen sign
followed by Japanese, it works OK. When the Yen sign is followed by English, it
does not work. I suspect that the layout engine is using 8-bit units on Win9x
and our backslash/yen fix is not working in that case. Need to confirm this.
Yen sign is important, and Win9x is important. Adding rtm keyword to get this on
the radar.

Comment 10

[Teruko Kobayashi]

Just FYI.  This is not reproduciable in 2000-10-19-08 MN6 build on Linux and Mac system.

Comment 11

[Teruko Kobayashi]

cc'd [e-mail] and [e-mail].

Comment 12

[Erik van der Poel]

Teruko, please try Yen sign followed by English on US Win95 and US Win98 (with
charset=shift_jis). Thanks.

Comment 13

[Teruko Kobayashi]

I tested this on Windows ME J in 200-10-20MN6 build.
In composer, when I type yen sign only, it is displayed as "・".
However, when I type some Japanese characters after the yen sign,
it becames yen sign and some Japanese characters.

If I type yen sign and ASCII characters, it is still displayed as
"・".

Comment 14

[Erik van der Poel]

Attachment: Yen sign followed by ASCII, and Yen sign followed by Kanji

Comment 15

[Erik van der Poel]

I tried US Win95, and the bug does not occur there. So, this is not a Win9x vs
NT problem. The problem only seems to occur on Japanese Win95/98/ME.

Comment 16

[msanz]

Frank, can you triage this bug? I think it's important.

Comment 17

[Frank Tang]

I think thit is very important for Japanese Win95/98 users. We should consider 
fix it.

Comment 18

[Jaime Rodriguez, Jr.]

I agree with Ftang.

Comment 19

[Erik van der Poel]

Attachment: fix in nsTextTransformer.cpp

Comment 20

[Erik van der Poel]

Steve and Chris, here's an explanation of the fix that I just attached to this bug
report. nsTextFrame has a couple of methods called PaintAsciiText and
PaintUnicodeText. It calls nsTextTransformer::HasMultibyte to see whether the text
has any chars greater than 127. The problem is that nsTextTransformer only sets
that bit (HasMultibyte) for any chars > 127 in the *input* text (before
transformation). In our fix for bug 4238, we forgot to set that bit for the
*output* text (after transformation). So this fix sets the bit in our output
text (in the code that was added to fix bug 4238). This makes nsTextFrame call
the right Paint routine (PaintUnicodeText) on Win95/98/ME (which has the fast
rendering hint in nsRenderingContextWin).

Comment 21

[Chris Waterson]

Looks fine. sr=waterson

Comment 22

[Erik van der Poel]

Fix checked into trunk. Teruko, please test the next trunk builds on all
platforms (US/Japanese Win95/98/NT, Linux, Mac) to make sure the bug is fixed
and also no new bugs have been introduced. Thanks.

Comment 23

[Jim Roskind]

Correcting marking to "rtm-plus" so that PDT will notice it (we got email today
suggesting that folks were requesting limbo inclusion).

The patch seems small and safe, and the benefit nice for I18n.
Moving to candidate limbo.
Please report any regressions seen on the trunk in this bug.
Anticipate that IF our limbo 1 build proves viable, we might be marking this bug
double plus RSN.  Pleaes wait for the approval before landing on the RTM branch.
 Consider helping in the limbo 1 testing to facilitate taking this next limbo
slew of fixes.
Thanks,
Jim

Comment 24

[Teruko Kobayashi]

I tested this in 2000-11-01-09 Win32, Mac, and Linux MTrunk builds
on Win98J, Win95J, WinMEJ, Winnt4.0J, Windows 2000J, System 9.0J, and
Redhat 6.2J.  This works fine on all platforms.

Comment 25

[Teruko Kobayashi]

I also tested same build on Win95US, Win98US, and Winnt4.0US. This works fine on
all platforms.

Comment 26

[selmer (gone)]

rtm++, please checkin ASAP so we can build today.

Comment 27

[Erik van der Poel]

Fix checked into branch. Marking FIXED.

Comment 28

[Teruko Kobayashi]

Verified as fixed in 2000-11-02-09 MN6 Mac, Linux, and Win32 builds on Win95J,
Win95US, Win98J, Win98US, Winnt4.0J, WinMEJ, System 9.0J, and Redhat 6.2J.