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

VERIFIED FIXED in M18

Status

()

Core
Internationalization
P2
major
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: Teruko Kobayashi, Assigned: Erik van der Poel)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(3 attachments)

(Reporter)

Description

19 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 "�`"
(Reporter)

Updated

19 years ago
Target Milestone: M4
(Reporter)

Comment 1

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

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 2

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

Updated

19 years ago
Target Milestone: M4 → M6

Comment 3

19 years ago
Mark it as M6

Updated

19 years ago
Target Milestone: M6 → M8

Comment 4

19 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)
(Assignee)

Comment 5

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

Comment 6

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

Updated

19 years ago
Blocks: 7228
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

19 years ago
Target Milestone: M9 → M7

Comment 7

19 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?
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 8

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

Updated

19 years ago
Status: REOPENED → ASSIGNED
Target Milestone: M7 → M9

Comment 9

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

Updated

19 years ago
Resolution: FIXED → ---

Comment 10

19 years ago
Clearing Fixed resolution.

Updated

19 years ago
Assignee: ftang → erik
Status: ASSIGNED → NEW
Target Milestone: M9 → M10

Comment 11

19 years ago
we still donot know how to deal with this. Reassign this to erik.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M10 → M15
(Assignee)

Comment 12

19 years ago
Accepting this bug, but we should discuss this some more...
(Reporter)

Updated

19 years ago
Blocks: 4237
(Assignee)

Comment 13

19 years ago
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16
(Assignee)

Comment 14

19 years ago
Prioritizing my bugs. This one is now M19.
Target Milestone: M16 → M19
(Reporter)

Comment 15

18 years ago
I am nominating this for beta3.
Keywords: nsbeta3

Updated

18 years ago
Priority: P3 → P2
Whiteboard: [nsbeta3+]

Comment 16

18 years ago
Marking nsbeta3+ per I18N bug triage.
(Reporter)

Comment 17

18 years ago
Changed platform to all.
OS: Windows 95 → All
Hardware: PC → All

Comment 18

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

Comment 19

18 years ago
Mac and Linux have the problem

Comment 20

18 years ago
somehow I am able to display yen sign on mac if it is in .txt file, but not in 
.html file 
(Reporter)

Comment 21

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

Comment 22

18 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 \ ?
(Reporter)

Comment 23

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

Comment 24

18 years ago
PDT thinks this could be P3. Setting priority and leaving [PDTP3] breadcrumb
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]

Comment 25

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

Comment 26

18 years ago
erik have a patch. I have reviewed it. 
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3+][PDTP3], patch in hand and reviewed. wait for check in.

Comment 27

18 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.
Priority: P3 → P2
(Assignee)

Comment 28

18 years ago
Created attachment 14786 [details] [diff] [review]
this patch uses nsTextTransformer to fix the bug
(Assignee)

Comment 29

18 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
(Assignee)

Comment 30

18 years ago
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
(Assignee)

Comment 31

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

Comment 32

18 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.
(Assignee)

Comment 33

18 years ago
Created attachment 15011 [details] [diff] [review]
updated patch, with buster's input

Comment 34

18 years ago
Removing myself from CC list.

Comment 35

18 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?
(Assignee)

Comment 36

18 years ago
Created attachment 15040 [details] [diff] [review]
updated patch, based on waterson's comments (thanks)
(Assignee)

Comment 37

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

Comment 38

18 years ago
looks great to me.
(Assignee)

Comment 39

18 years ago
Checked in the fix. Thanks for the reviews.
Whiteboard: [nsbeta3+][PDTP2] patch attached; awaiting super review → [nsbeta3+][PDTP2] fix checked in

Comment 40

18 years ago
erik check in the fix
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 41

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