Closed Bug 4238 Opened 21 years ago Closed 19 years ago

Hankaku "\" and "~" are not displayed correctly

Categories

(Core :: Internationalization, defect, P2, major)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: teruko, Assigned: erik)

References

()

Details

(Whiteboard: [nsbeta3+][PDTP2] fix checked in)

Attachments

(3 files)

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 "�`"
Target Milestone: M4
The page is created by using Shift_JIS and I tested in Windows 95J and Winnt 4.0J.
Status: NEW → ASSIGNED
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.
Target Milestone: M4 → M6
Mark it as M6
Target Milestone: M6 → M8
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.
Blocks: 7228
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: M9 → M7
Changed TFV to M7 -- the first M-build for which fix will first appear.

Frank, Can you provide info on how this was fixed?
Status: RESOLVED → REOPENED
I tested this in 6-16-09 Win32 build.  This still happen, so I reopen this.
Status: REOPENED → ASSIGNED
Target Milestone: M7 → M9
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.
Resolution: FIXED → ---
Clearing Fixed resolution.
Assignee: ftang → erik
Status: ASSIGNED → NEW
Target Milestone: M9 → M10
we still donot know how to deal with this. Reassign this to erik.
Status: NEW → ASSIGNED
Target Milestone: M10 → M15
Accepting this bug, but we should discuss this some more...
Blocks: 4237
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16
Prioritizing my bugs. This one is now M19.
Target Milestone: M16 → M19
I am nominating this for beta3.
Keywords: nsbeta3
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Marking nsbeta3+ per I18N bug triage.
Changed platform to all.
OS: Windows 95 → All
Hardware: PC → 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
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
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. 
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3+][PDTP3], patch in hand and reviewed. wait for check in.
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.
Priority: P3 → P2
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.
Whiteboard: [nsbeta3+][PDTP3], patch in hand and reviewed. wait for check in. → [nsbeta3+][PDTP2], patch in hand and reviewed. wait for check in.
Target Milestone: M19 → M18
Chris and Robert, if either of you can get to this review before Steve does,
that would be appreciated.
Whiteboard: [nsbeta3+][PDTP2], patch in hand and reviewed. wait for check in. → [nsbeta3+][PDTP2] patch attached; awaiting super review
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.
Whiteboard: [nsbeta3+][PDTP2] patch attached; awaiting super review → [nsbeta3+][PDTP2] fix checked in
erik check in the fix
Status: ASSIGNED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
I verified this in 2000-09-21-08 Win32, 2000-09-21-04 Mac, and 2000-09-21-10 
Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.