When viewing in Big5, numbers are not displayed at all

VERIFIED FIXED

Status

()

Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Shao Zhang, Assigned: Frank Tang)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++], URL)

(Reporter)

Description

18 years ago
Produced using the nightly 2000093021 build.
When viewing the above site using big5, the numbers(ie. 1,2,3..) are not
displayed at all.

The problem occurs in both the dropdown list and the article.
See the date in the dropdown list

Comment 1

18 years ago
Hi, I'm the reporter of bug 52729, which describes a similar symptom on Linux.
I'm see the same problem described in this bug as well. Due to the fact that
this behavior started sometime around 9/11/2000, I believe this bug is related
to bug 52655, which has been marked as FIXED. However, I do not believe 52655
has been entirely fixed.

I made the following observation:

1. Remove your current Mozilla profile in ~/.mozilla
2. Start Mozilla. Mozilla should create a new profile. Notice that by default,
no Big5 fonts are specified in pref.js
3. Go to the above URL, or any other Big5 pages. The numbers and characters
should show up correctly.
4. Go to Edit->preference->fonts, change the encoding to "Traditional Chinese",
and select a Big5 font for ALL of serif, sans serif, and monospaced fonts.
5. Click OK to make the changes
6. Mozilla will try to re-render the page. Now notice that numbers as well as
some English letters will disappear
7. Try to "view frame source". You should see the exact same problem as
described in bug 52655

In effect, this prevents users from specifying a custom Big5 font. Big5 pages
will only render correctly when there is no Big5 font settings in pref.js

I'm not sure if this applies to other CJK languages as well. My system is
Mandrake 7.0 + CLE 0.9 (Chinese Linux Extension, see http://cle.linux.org.tw/),
and my currently Mozilla build is 2000092908.

Comment 2

18 years ago
Reassign to erik, cc to ji.
Xianglan, are you able to reproduce?
Assignee: nhotta → erik

Comment 3

18 years ago
Using linux 2000100208-M18 mozilla build, I can't reproduce the problem.
The system I used is RH6.2 with big5 fonts.

Comment 4

18 years ago
Frank, I found that the x-x-big5 converter is returning an nsICharRepresentable
array with the bits set for ASCII chars (0-127).
Assignee: erik → ftang
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

18 years ago
with m18-2000100208, i could reproduce what Danny described.
I also noticed that simplified chinese, japanese are not having this problem.

Comment 6

18 years ago
clkao, which system did you use?

Comment 7

18 years ago
i'm sorry that i forgot to mention that I am using debian woody, the default
chinese font (with pref.js untouched) seemed to be taipei24, alias as
-eten-fixed-medium-r-normal--24-230-75-75-c-240-big5-0,
which is the last entry of `xlsfont|grep big5-0`.

but if i change triditional chinese font setting to default-ming-big5-0, i can't
see any ascii characters.

Comment 8

18 years ago
Yes, I saw this problem too on my Red Hat after selecting eten-taipei-big5.et-0
for Traditional Chinese.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: rtm
(Assignee)

Comment 9

18 years ago
mark it as assign and RTM
(Assignee)

Comment 10

18 years ago
I think we need to fix this for rtm. However, I don't have a fix for it yet.
Whiteboard: [rtm+ need info]
(Assignee)

Comment 11

18 years ago
here is the fix
Index: ucvtw/nsUnicodeToBIG5NoAscii.cpp
===================================================================
RCS file: /m/pub/mozilla/intl/uconv/ucvtw/nsUnicodeToBIG5NoAscii.cpp,v
retrieving revision 1.3
diff -u -r1.3 nsUnicodeToBIG5NoAscii.cpp
--- nsUnicodeToBIG5NoAscii.cpp	2000/02/08 06:21:17	1.3
+++ nsUnicodeToBIG5NoAscii.cpp	2000/10/05 00:57:59
@@ -52,3 +52,13 @@
   *aDestLength = 2 * aSrcLength;
   return NS_OK_UENC_EXACTLENGTH;
 }
+NS_IMETHODIMP nsUnicodeToBIG5NoAscii::FillInfo(PRUint32 *aInfo)
+{
+  nsresult rev = nsTableEncoderSupport::FillInfo(aInfo); // call the super class
+  if(NS_SUCCEEDED(rev))
+  {
+    // mark the first 128 bits as 0. 4 x 32 bits = 128 bits
+    aInfo[0] = aInfo[1] = aInfo[2] = aInfo[3] = 0;
+  }
+  return rev;
+}
Index: ucvtw/nsUnicodeToBIG5NoAscii.h
===================================================================
RCS file: /m/pub/mozilla/intl/uconv/ucvtw/nsUnicodeToBIG5NoAscii.h,v
retrieving revision 1.3
diff -u -r1.3 nsUnicodeToBIG5NoAscii.h
--- nsUnicodeToBIG5NoAscii.h	2000/02/08 06:21:17	1.3
+++ nsUnicodeToBIG5NoAscii.h	2000/10/05 00:57:59
@@ -41,6 +41,7 @@
    */
   nsUnicodeToBIG5NoAscii();

+  NS_IMETHOD FillInfo(PRUint32 *aInfo);
 protected:

   //--------------------------------------------------------------------


you can also find it from http://warp/u/ftang/tmp/fix54841.txt

Comment 12

18 years ago
I have tested and reviewed the fix. It works fine, and the code looks good too,
except that I would rename "rev" to "rv" or "ret". r=erik
(Assignee)

Updated

18 years ago
Whiteboard: [rtm+ need info] → [rtm+ need info]r=erik need superreview
(Assignee)

Comment 13

18 years ago
pdt, please consider this as rtm++
The code is only used in Linux for using Traditional Chinese font. Usually it is
used while we view traditional Chinese document.
Whiteboard: [rtm+ need info]r=erik need superreview → [rtm+]
(Assignee)

Comment 14

18 years ago
This is the safest fix I can find without changing the whole conversion table.
We zero out the first 128 bits of the representable array so we won't use Big5
font on Linux to display ASCII. This converter is only used for BIG5 font on
Linux. Sending Big5 document (Post, composer save as, or email) does not use
this converter so there are no risk to break them.
I agree with erik about using rv (the canonical name) and not rev (revision?
hrm).  a=brendan@mozilla.org on this spot-fix.

/be

Comment 16

18 years ago
rtm++
Whiteboard: [rtm+] → [rtm++]
(Assignee)

Comment 17

18 years ago
check into trunk. Not check into branch yet.
(Assignee)

Comment 18

18 years ago
check into the branch friday afternoon.
(Assignee)

Comment 19

18 years ago
see latest comment
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 20

18 years ago
Verified with 2000100909 branch build. It is fixed.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
(Assignee)

Comment 21

18 years ago
*** Bug 56591 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
Reopening to Resolve as Fixed.  Bugs stay resolved until verified on both the
branch and the trunk.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 23

18 years ago
Resolving as Fixed.  vtrunk keyword is in place requesting trunk verification
before this bug changes state to Verified.  When this is verified on the trunk
vtrunk keyword should be removed and the bug Status should be set to Verified.
Sorry for the spam, just trying to make sure we cover all of our bases here.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 24

18 years ago
Verified as fixed in 2000-12-12-09 Mtrunk Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.