Closed Bug 267670 Opened 20 years ago Closed 20 years ago

REGRESSION: Rendering with incorrect font and charset encoding

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
major

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.
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?
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
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.
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 → ---
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.

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.
Marking WFM as the reporter noted it all worked correctly with a fresh profile.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: