Tested 3-23-99 Win32 build. In the above URL page, the test case #3 has Hankaku Yen sign. However, Hankaku Yen sign is displayed as Hankaku back slash. The test case #17 has Hankaku chiruda "~". However, "~" is displayed as "�`"

The page is created by using Shift_JIS and I tested in Windows 95J and Winnt 4.0J.

This bug come back to us AGAIN. We have to decide how to convert 0x5c and 0x7e in Shift_JIS,ISO-2022-JP, and EUC-JP.

Mark it as M6

We have discuss and decide to solve this not from the conversion side, but from the GFX side, e.g. GFX in each platform should listen to the document charset and decide how to render these. However, this is depend on passing the "document charset" in nsFont to work. We should change this to a window only bug and reassign to erik and create three other new bug, one for mac (assign to ftang), one for GTK (assign to erik), and one for PostScript GFX (assign to erik and cc dcone)

I remember discussing this, and that I said that it might be a good idea to do this down at the font level (GFX), but I am now wondering whether we can do this in an efficient manner. Remember, in GFX we are rendering and *measuring* text. If we have to change the Unicode from 0x005C to 0x00A5, then that means that we probably have to copy the text to another buffer. We have to copy in some cases anyway (e.g. GTK, Win95-J), but in other cases (Win32) we currently pass the Unicode as is (without copying). Let's discuss some more...

Frank will probably be out on paternity leave during M8. Moved to M9.

Changed TFV to M7 -- the first M-build for which fix will first appear. Frank, Can you provide info on how this was fixed?

I tested this in 6-16-09 Win32 build. This still happen, so I reopen this.

I must accidentally mark this fixed. Sorry for that. This should not be M7. I think this should be M9 and fixed in rendering code.

Clearing Fixed resolution.

we still donot know how to deal with this. Reassign this to erik.

Accepting this bug, but we should discuss this some more...

Moving all of my M15s to M16. Please add comments if you disagree.

Prioritizing my bugs. This one is now M19.

I am nominating this for beta3.

Marking nsbeta3+ per I18N bug triage.

Changed platform to all.

Does this happen to all platform ? I cannot reproduce this on window.

Mac and Linux have the problem

somehow I am able to display yen sign on mac if it is in .txt file, but not in .html file

Frank, when I type backslash in Composer with Winnt 4.0J, it is displayed as backslash, not "Yen" sign. When I look at the html page in Browser, it is diaplayed as "Yen" sign. "~" is displayed fine in Composer and Browser.

teruko, if you select one of the Japanesse encoding "ISO-2022-JP", "Shift-JIS" or "EUC-JP" in the View:Character Coding" menu right after you open the composer and start typing, will that display yen or \ ?

That's the way I tested before. After I changed character coding menu to Shift_JIS, EUC-JP, and ISO-2022-JP, the backslash (not yen sign) will be displayed when I type the backslash in composer in Windows build. That's not right.

PDT thinks this could be P3. Setting priority and leaving [PDTP3] breadcrumb

The reason it was P2 is because YEN sign is the money sign in Japan. Ship without this is similar with with display $ sign incorrectly in US. This bug may cause a lot of trouble for us in Japan.

erik have a patch. I have reviewed it.

Mark as P2 since this may impact important e-commerce in Japan. The problem is similar if we display $ sign as something else in US.

Hi Steve, Frank and I are going to talk to the PDT to bump this bug up to PDTP2 status, since it involves the Yen Sign, which is as important as the Dollar Sign (in Japan). The Unicode converter converts 0x5C in the Japanese charsets (yen sign) to 0x005C in Unicode (backslash), since there are dependencies on that code point, such as the directory name separator (\) on Windows. Also, Microsoft and other major vendors convert Japanese 0x5C to Unicode 005C too. So, our solution is to use nsTextTransformer to convert 5C to A5 (Yen Sign) just before measuring and drawing the text. It only goes down this code path for Japanese and Korean charsets, which are determined by nsPresContext, the logical place to do this since it already needed that info for fonts anyway. The code has been carefully written not to impact other languages (such as English). As one of the reviewers listed for the layout module, would you please review the attached patch? Thanks, Erik

PDTP2, per phil/michaell; yen sign is important.

Chris and Robert, if either of you can get to this review before Steve does, that would be appreciated.

Erik: In general, the patch looks good. I have a few minor concerns that we should talk about before you check this in. I'll send them to you directly.

Removing myself from CC list.

- Add a comment before the call to nsPresContext::Observe() to indicate what you're doing? (What'll happen when somebody else adds junk to the Observe method?) - Why not put "ja" and "ko" atoms in nsLayoutAtoms? - Does this add yet another pass through the text before passing drawing? How often do we end up in this code?

>- Add a comment before the call to nsPresContext::Observe() to indicate what >you're doing? (What'll happen when somebody else adds junk to the Observe >method?) Moved contents of Observe() method to new UpdateCharSet() method to make it more obvious, and protected Observe() from new callers. >- Why not put "ja" and "ko" atoms in nsLayoutAtoms? Done. >- Does this add yet another pass through the text before passing drawing? How >often do we end up in this code? Yes, there is another pass through the text, but only for Japanese and Korean. We do this just before measuring and just before drawing the text. (We'd rather not do this extra stuff, but see the motivation above.)

looks great to me.

Checked in the fix. Thanks for the reviews.

erik check in the fix

I verified this in 2000-09-21-08 Win32, 2000-09-21-04 Mac, and 2000-09-21-10 Linux build.