Closed Bug 170839 Opened 23 years ago Closed 23 years ago

page displays fonts incorrectly

Categories

(Camino Graveyard :: Page Layout, defect)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 170569

People

(Reporter: matkam, Assigned: bryner)

References

(
URL
)

Details

Attachments

(2 files)

Reduced test case of versiontracker
573 bytes, text/html
Details
Same test case except that chinese character has been removed
571 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020925 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020925 The font for program names at http://www.versiontracker.com/macosx/ displays incorrectly. If i make the font bigger, it looks fine (just too big). Reproducible: Always Steps to Reproduce:
btw, i made the font bigger by using command =
I can duplicate this one too using the following build Mac OS X 10.2.1, Chimera 2002-09-25-04 But I think that it is the problem with "www.versiontracker.com" because of the following - 1. In Mozilla, I can reproduce this and Mozilla is choosing the wrong Locale setting for this page. Once I have choose to use the Western encoding, Mozilla shows the page correctly. 2. I cannot see problem in other pages.
Hmm, now I see this using Chimera/2002092304, but not FizzillaCFM/2002091708, on 10.1.5. Michael, what encoding was Mozilla showing before you forced Western?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmmm. I see the problem too but can't seem to reproduce from a local copy of the page. Page uses a css external file (http://www.versiontracker.com/vt.css) that specifies css properties. Most of the distorted text on this page has been assigned the "product" class. Here is the class reference in the external file: .product { font-family: sans-serif; font-size: 13px; color: #000000; text-decoration: none; font-weight: bold;} But like I said, I can't trouble shoot this problem since I'm not able to reproduce when the file is local.
The OSX section of VersionTracker renders text poorly because it's missing the header: ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
Actually , that DTD would invoke gecko's "standards" mode but I don't believe that is the reason. Versiontracker's pages use the following DTD which invokes gecko's "quirks" mode. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> Since vt's pages use quirks mode then you would see the font problem on all of the pages.
Using Mozilla, I can reproduce the font problem with vt if I change the character coding to Chinese Traditional (Big 5). Tested using 2002-09-27-08 and OS 10.2.1. Maybe something is triggering Chimera to use a different character code ?
*** Bug 171613 has been marked as a duplicate of this bug. ***
Version tracker have added the doctype to their page - so it's not that.
> Using Mozilla, I can reproduce the font problem with vt if I change the character coding to Chinese Traditional (Big 5) I think this is closest to the money. Look for non-ascii in the page that might cause this.
Yep, I found the problem. A link on the page contains a chinese character in it's HREF. If I remove this character from the HREF, the table which contains the font element is no longer rendered incorrectly. Test case coming.
The link below the table contains a chinese character in the HREF. This will cause the font element in the table (which is inside a seperate HREF) to render incorrectly.
Font in table is rendered correctly.
Looks like VT changed their page since the font problem isn't occuring today (10/01). HTML code from the OS X page no longer contains the chinese character in a HREF.
I guess I wonder if VT is explicitly identifying its' charset, and if so, was Chimera trying to override it because it detected what it thought was a Chinese character? I don't think Chimera should do that.
You have to do that, because there are many, many pages which incorrectly identify their charset.
VersionTracker seems to have fixed their fonts, the problem may not be a Chimera Issue. I am testing on 2002-10-02-04 build using Mac OS X 10.2.1
Note that this is a dup of bug 170569.
*** This bug has been marked as a duplicate of 170569 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: