3.87 KB, text/html
3.79 KB, text/html
173 bytes, text/html
1.04 KB, patch
|Details | Diff | Splinter Review|
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.
See 92(0x5c) cell in the attached table.
Reassign to erik.
Assignee: nhotta → erik
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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.
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.
Status: NEW → ASSIGNED
Just FYI. This is not reproduciable in 2000-10-19-08 MN6 build on Linux and Mac system.
Teruko, please try Yen sign followed by English on US Win95 and US Win98 (with charset=shift_jis). Thanks.
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 "・".
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.
Frank, can you triage this bug? I think it's important.
I think thit is very important for Japanese Win95/98 users. We should consider fix it.
Whiteboard: [rtm+ need info]
I agree with Ftang.
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).
Looks fine. sr=waterson
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.
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
Whiteboard: [rtm+ need info] → [rtm+]
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.
I also tested same build on Win95US, Win98US, and Winnt4.0US. This works fine on all platforms.
rtm++, please checkin ASAP so we can build today.
Whiteboard: [rtm+] → [rtm++]
Fix checked into branch. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.