0x5c should be displayed as yen sign




19 years ago
14 years ago


(Reporter: kazhik, Assigned: erik)


Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm++])


(4 attachments)



19 years ago
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

Comment 1

19 years ago
Created attachment 17660 [details]

Comment 2

19 years ago
Created attachment 17663 [details]
Testcase(no charset specification)

Comment 3

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

Comment 4

19 years ago
Reassign to erik.
Assignee: nhotta → erik

Comment 5

19 years ago
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. 

Ever confirmed: true

Comment 6

19 years ago
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

19 years ago
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

19 years ago
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

19 years ago
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.
Keywords: rtm

Comment 10

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

Comment 11

19 years ago
cc'd jaimejr@netscape.com and msanz@netscape.com.

Comment 12

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

Comment 13

19 years ago
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

19 years ago
Created attachment 17911 [details]
Yen sign followed by ASCII, and Yen sign followed by Kanji

Comment 15

19 years ago
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

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

Comment 17

19 years ago
I think thit is very important for Japanese Win95/98 users. We should consider 
fix it.
Whiteboard: [rtm+ need info]
I agree with Ftang.

Comment 19

19 years ago
Created attachment 18350 [details] [diff] [review]
fix in nsTextTransformer.cpp

Comment 20

19 years ago
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

19 years ago
Looks fine. sr=waterson

Comment 22

19 years ago
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

19 years ago
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.
Whiteboard: [rtm+ need info] → [rtm+]

Comment 24

19 years ago
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

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

Comment 26

19 years ago
rtm++, please checkin ASAP so we can build today.
Whiteboard: [rtm+] → [rtm++]

Comment 27

19 years ago
Fix checked into branch. Marking FIXED.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 28

19 years ago
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.
You need to log in before you can comment on or make changes to this bug.