Closed
Bug 54841
Opened 24 years ago
Closed 24 years ago
When viewing in Big5, numbers are not displayed at all
Categories
(Core :: Internationalization, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: shao, Assigned: ftang)
References
()
Details
(Whiteboard: [rtm++])
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
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•24 years ago
|
||
Reassign to erik, cc to ji. Xianglan, are you able to reproduce?
Assignee: nhotta → erik
Using linux 2000100208-M18 mozilla build, I can't reproduce the problem. The system I used is RH6.2 with big5 fonts.
Comment 4•24 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
with m18-2000100208, i could reproduce what Danny described. I also noticed that simplified chinese, japanese are not having this problem.
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.
Yes, I saw this problem too on my Red Hat after selecting eten-taipei-big5.et-0 for Traditional Chinese.
Assignee | ||
Comment 9•24 years ago
|
||
mark it as assign and RTM
Assignee | ||
Comment 10•24 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•24 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•24 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•24 years ago
|
Whiteboard: [rtm+ need info] → [rtm+ need info]r=erik need superreview
Assignee | ||
Comment 13•24 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•24 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.
Comment 15•24 years ago
|
||
I agree with erik about using rv (the canonical name) and not rev (revision? hrm). a=brendan@mozilla.org on this spot-fix. /be
Assignee | ||
Comment 17•24 years ago
|
||
check into trunk. Not check into branch yet.
Assignee | ||
Comment 18•24 years ago
|
||
check into the branch friday afternoon.
Assignee | ||
Comment 19•24 years ago
|
||
see latest comment
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 20•24 years ago
|
||
Verified with 2000100909 branch build. It is fixed.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Assignee | ||
Comment 21•24 years ago
|
||
*** Bug 56591 has been marked as a duplicate of this bug. ***
Comment 22•24 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•24 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
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 24•24 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.
Description
•