Closed
Bug 267670
Opened 20 years ago
Closed 20 years ago
REGRESSION: Rendering with incorrect font and charset encoding
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: j4nu5.n6, Assigned: mikepinkerton)
References
()
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041102 Camino/0.8.2 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041102 Camino/0.8.2 A few web pages rendered with incorrect font and encoding. It affects some page in the collapsed drop down menu (SELECT tag) only. Reproducible: Always Steps to Reproduce: Example A) about incorrect font and encoding in whole page: 1. download Camino 0.8.2 preview from http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2004-11-03-06-0.8.2/Camino.dmg.gz 2. go to uri: http://appletalk.rhapsody.com.hk:443/appletalk/ Example B) about incorrect font and encoding in collapsed drop down menu only: 1. download Camino 0.8.2 Preview from http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2004-11-03-06-0.8.2/Camino.dmg.gz 2. go to the uri: http://www.gamehit.net/index.php?act=ST&f=25&t=33827&s=41491609aec20ab93eaa8abf28979df8 Actual Results: In example A, the whole page rendered with incorrect font and encoding (Shift-JIS ?) In example B, the drop down menu in the lower right hand corner rendered with incorrect font and encoding (Shift-JIS ?) while collapsed. Expected Results: Example A, the whole page are rendered in Big5-HKSCS encoding Example B, the whole page are rendered in Big5 encoding including the drop down menu. This bug was not in the Camino 0.8.1 release. In example A, the page are rendered correctly if ignored the css file http://appletalk.rhapsody.com.hk:443/appletalk/%E8%98%8B%E7%8B%82%E9%99%A3Appletalk%20%E8%A8%8E%E8%AB%96%E5%8D%80%20%20%20%20%E9%A6%96%E9%A0%81%20Files/fiapple.css In example B, the drop down menu are rendered correctly while expanded.
Camino 0.8.1 rendered correctly on http://appletalk.rhapsody.com.hk:443/appletalk/viewtopic.php?p=44572#44572
Comment 5•20 years ago
|
||
Both examples WFM using the same 0.8.2 build. Both pages are rendered using Big5 (not HKSCS).
(In reply to comment #5) Do you mean they are rendered correctly? Besides, I forgotten that for example A, the default encoding is big5. However, while registration as a member, there is an option to change the encoding to Big5-HKSCS. And after logged in, the fifth line of the source of the web page would become "<meta http-equiv="Content-Type" content="text/html; charset=big5-hkscs" />" Sorry for the confusion. I have forgotten that memeber option.
The response of a Web server can be checked to the following sites. http://web-sniffer.net/ Is the character code of a Web server response the same as the character code of the HTML document actually outputted?
Assignee | ||
Comment 8•20 years ago
|
||
so what's the deal here? is this WFM or a bona fide regression? it's one of the few things holding up 082, we need a definitive answer or much more detail.
WFM using 0.8.2 beta on 10.3.5. Also works on trunk builds. I say we mark A WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 10•20 years ago
|
||
After changed font settings in Camino, it shows the page correctly in both Big5-HKSCS and Big5. The font I was using for monospace in both Big5 and Big5-HKSCS was Arial Unicode (from Microsoft Windows). Now I have set it to LiHei Pro. Everything is fine now. It seems the bug is font related. Anyway, I think it should not hold back 0.8.2 release.
Reporter | ||
Comment 11•20 years ago
|
||
I think I understand the problem a bit more now. Camino 0.8.2 does not follow the font specified in the Appearance preferences. (prefs.js file) As least it is the case for Traditional Chinese (zh_TW). Sometime some characters are missing. In fact, I hve filed a separate bug, bug 268814, for it but now I think it is the same bug. It may or may not happen at launch but it get worse over time in the running session. It really rendered Camino 0.8.2 unusable in Traditional Chinese web pages.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 12•20 years ago
|
||
After Further investigation, I have found the Camino 0.8.2PR problem involve the custom user.js preferences file and switching between Big5-HKSCS and Big5 encoding. Since Camino does not have a way to change the font settings for Big5-HKSCS(zh-HK) encoded page from Preferences, I have added the following lines into user,js file: <--begin--> user_pref("font.minimum-size.zh-HK", 14); user_pref("font.name.cursive.zh-HK", "LiHei Pro"); user_pref("font.name.fantasy.zh-HK", "LiHei Pro"); user_pref("font.name.monospace.zh-HK", "LiHei Pro"); user_pref("font.name.sans-serif.zh-HK", "LiHei Pro"); user_pref("font.name.serif.zh-HK", "LiSong Pro"); user_pref("font.size.fixed.zh-HK", 15); user_pref("font.size.variable.zh-HK", 18); <--end--> Basically, it is the same setting as for my Big5 web page. LiHei Pro and LiSung Pro contains all the Big5-HKSCS glyths. And Big5-HKSCS is a superset of Big5; therefore, they work for both encoding. The font on web pages would go weird sometimes after a few switching between Big5 and Big5 encoded pages. Eventually it will draw blanks for some characters, highlighting characters shifts their positions, spacing incorrectly and overflow the page, etc. Even worse, the problem goes on for next launches of Camino. Even a fresh copy of Camino 0.8.2PR does not fix them. It will affect both Big5 and Big5-HKSCS encoded pages. The only to restore it is to remove all the zh-HK settings in both user.js and prefs.js. Then the problem will gone after a few relaunch of Camino. The problem has not surfaced in all Camino version up to 0.8.1. Note: For the record, as many of web pages contain Big5-HKSCS encoded characters but declared as Big5 charset, people in Hong Kong has to manually switch the encoding to Big5-HKSCS for some mis configurated pages. I have changed the following line Camino.app/Contents/Mac OS/res/charsetalias.properties to force Camino to render them in Big5-HKSCS and saves my time. was: big5=Big5 now: big5=Big5-HKSCS I have confirmed that changing-the-encoding-manually-to-Big5-HKSCS-from-menu would trigger the same problem even without messing-around-charsetalias.properties-file.
Reporter | ||
Comment 13•20 years ago
|
||
After a fresh new installed Mac OS X and Camino. The problem was there until I have swtiched to another profile. I seems to be something in the old profile that caused the problem in 0.8.2 but I am not going to trace that. It works now. Sorry for stirring.
Comment 14•20 years ago
|
||
Marking WFM as the reporter noted it all worked correctly with a fresh profile.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•