54841 - When viewing in Big5, numbers are not displayed at all

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Shao Zhang]

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

[Danny]

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

[nhottanscp]

Reassign to erik, cc to ji.
Xianglan, are you able to reproduce?

Comment 3

[ji]

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

Comment 4

[Erik van der Poel]

Frank, I found that the x-x-big5 converter is returning an nsICharRepresentable
array with the bits set for ASCII chars (0-127).

Comment 5

[clkao]

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

Comment 6

[ji]

clkao, which system did you use?

Comment 7

[clkao]

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

[ji]

Yes, I saw this problem too on my Red Hat after selecting eten-taipei-big5.et-0
for Traditional Chinese.

Comment 9

[Frank Tang]

mark it as assign and RTM

Comment 10

[Frank Tang]

I think we need to fix this for rtm. However, I don't have a fix for it yet.

Comment 11

[Frank Tang]

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

[Erik van der Poel]

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

Comment 13

[Frank Tang]

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.

Comment 14

[Frank Tang]

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.

Comment 15

[Brendan Eich [:brendan]]

I agree with erik about using rv (the canonical name) and not rev (revision?
hrm).  a=[e-mail] on this spot-fix.

/be

Comment 16

[Phil Peterson]

rtm++

Comment 17

[Frank Tang]

check into trunk. Not check into branch yet.

Comment 18

[Frank Tang]

check into the branch friday afternoon.

Comment 19

[Frank Tang]

see latest comment

Comment 20

[ji]

Verified with 2000100909 branch build. It is fixed.

Comment 21

[Frank Tang]

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

Comment 22

[Asa Dotzler [:asa]]

Reopening to Resolve as Fixed.  Bugs stay resolved until verified on both the
branch and the trunk.

Comment 23

[Asa Dotzler [:asa]]

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.

Comment 24

[Teruko Kobayashi]

Verified as fixed in 2000-12-12-09 Mtrunk Linux build.