Teruko Kobayashi Reporter
	Description • 26 years ago

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 "�`"

	Teruko Kobayashi Reporter
	Comment 1 • 26 years ago

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

	Frank Tang
	Comment 2 • 26 years ago

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.

	Frank Tang
	Comment 3 • 26 years ago

Mark it as M6

	Frank Tang
	Comment 4 • 26 years ago

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)

	Erik van der Poel Assignee
	Comment 5 • 26 years ago

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...

	bobj
	Comment 6 • 26 years ago

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

	bobj
	Comment 7 • 25 years ago

Changed TFV to M7 -- the first M-build for which fix will first appear.

Frank, Can you provide info on how this was fixed?

	Teruko Kobayashi Reporter
	Comment 8 • 25 years ago

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

	Frank Tang
	Comment 9 • 25 years ago

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.

	leger
	Comment 10 • 25 years ago

Clearing Fixed resolution.

	Frank Tang
	Comment 11 • 25 years ago

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

	Erik van der Poel Assignee
	Comment 12 • 25 years ago

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

	Erik van der Poel Assignee
	Comment 13 • 25 years ago

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

	Erik van der Poel Assignee
	Comment 14 • 25 years ago

Prioritizing my bugs. This one is now M19.

	Teruko Kobayashi Reporter
	Comment 15 • 24 years ago

I am nominating this for beta3.

	Jaime Rodriguez, Jr.
	Comment 16 • 24 years ago

Marking nsbeta3+ per I18N bug triage.

	Teruko Kobayashi Reporter
	Comment 17 • 24 years ago

Changed platform to all.

	Frank Tang
	Comment 18 • 24 years ago

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

	Frank Tang
	Comment 19 • 24 years ago

Mac and Linux have the problem

	Frank Tang
	Comment 20 • 24 years ago

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

	Teruko Kobayashi Reporter
	Comment 21 • 24 years ago

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.

	Frank Tang
	Comment 22 • 24 years ago

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 \ ?

	Teruko Kobayashi Reporter
	Comment 23 • 24 years ago

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.

	Phil Peterson
	Comment 24 • 24 years ago

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

	Frank Tang
	Comment 25 • 24 years ago

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. 

	Frank Tang
	Comment 26 • 24 years ago

erik have a patch. I have reviewed it. 

	Frank Tang
	Comment 27 • 24 years ago

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.

	Erik van der Poel Assignee
	Comment 29 • 24 years ago

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

	Erik van der Poel Assignee
	Comment 30 • 24 years ago

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

	Erik van der Poel Assignee
	Comment 31 • 24 years ago

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

	buster
	Comment 32 • 24 years ago

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.

	karnaze (gone)
	Comment 34 • 24 years ago

Removing myself from CC list.

	Chris Waterson
	Comment 35 • 24 years ago

- 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?

	Erik van der Poel Assignee
	Comment 37 • 24 years ago

>- 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.)

	Chris Waterson
	Comment 38 • 24 years ago

looks great to me.

	Erik van der Poel Assignee
	Comment 39 • 24 years ago

Checked in the fix. Thanks for the reviews.

	Frank Tang
	Comment 40 • 24 years ago

erik check in the fix

	Teruko Kobayashi Reporter
	Comment 41 • 24 years ago

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