Closed
Bug 396083
Opened 16 years ago
Closed 16 years ago
[10.5] Font handling picks up a new bold font; causes page layout issues
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: samuel.sidler+old, Assigned: jtd)
References
()
Details
(Keywords: regression, testcase)
Attachments
(7 files)
Opening the attached testcase on 10.5 will yield a doubly bold "Firefox" font. This larger font is different than how it appears on 10.4, presumably because Apple has changed some fonts around and our font handling does weird things with it. This affects a plethora of sites including: http://www.mozilla.org/products/ http://www.google.com/products http://www.gmail.com (logged in) Of the sites above, the second one has an actual layout issue due to the larger font -- I can attach a screenshot but basically it separate the "o" in the Google graphic because of how the page is laid out. These sites display fine in Safari. Tested using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre on 10.5 9A527.
Flags: blocking1.9?
Reporter | ||
Comment 1•16 years ago
|
||
Whoops. Forgot to attach the testcase. :-/
Reporter | ||
Comment 2•16 years ago
|
||
This is a screenshot of the testcase on 10.5. Minefield (the build in comment 0) is on the left and Firefox 2.0.0.6 is the on the right. This is a regression.
Reporter | ||
Updated•16 years ago
|
Keywords: regression,
testcase
Comment 3•16 years ago
|
||
this is 10.5 only?
Comment 4•16 years ago
|
||
The font looks fine to me running 10.4.10, so I would say this is only a 10.5 issue.
![]() |
||
Comment 5•16 years ago
|
||
Does the version of Arial shipped under 10.5 contain an 'extra-bold' or 'black' face (or similar name), in addition to a 'bold' face ? (check with FontBook) In which case, the display is correct and this bug is invalid. html.css specifies: strong {font-weight:bolder} That says use a bold face if the surrounding text is 'normal' and something even bolder if the specified font has a really bold face and the surrounding block is already using bold. 10.4 has only regular and bold for Arial, but ships a separate font 'Arial Black'. Under 10.4 you can see the same thing happening if the stylesheet uses: {font-family: Optima;}
![]() |
||
Comment 6•16 years ago
|
||
The same testcase as the first one, but specifying Optima for font-family. On 10.4, the word 'Firefox' is bolder, as Optima has an 'ExtraBlack' face.
Reporter | ||
Comment 7•16 years ago
|
||
Font Book does indeed show a "black" version of the Arial font. That may indeed mean we're following the spec, however, I don't think most of the web is used to this given the various issues I've seen. Regardless, I should probably test in the latest Webkit and file a bug there.
![]() |
||
Comment 8•16 years ago
|
||
Safari/WebKit builds have only limited support for various font-weight. (see: http://bugs.webkit.org/show_bug.cgi?id=6484) Can you also check what happens with Fx 2 (has better support for various font-weight then Fx 2 Mac) and Minefield on Vista ?
Comment 9•16 years ago
|
||
I don't see the bold font running Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8pre) Gecko/2007092505 BonEcho/2.0.0.8pre on Leopard. I used my Gmail inbox account as a reference because that is where I noticed it on the trunk on Leopard. I also don't see issues with the other two pages sam notes in his initial report.
Reporter | ||
Comment 10•16 years ago
|
||
Yeah, as I stated in comment 2, this doesn't happen on branch, only trunk.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Assignee | ||
Comment 11•16 years ago
|
||
Assignee | ||
Comment 12•16 years ago
|
||
Assignee | ||
Comment 13•16 years ago
|
||
Headers and text with Futura, 10.4 on the left, 10.5 on the right. On both 10.4 and 10.5, the Futura family contains four fonts: Futura Medium, Futura Medium Italic, Futura Condensed Medium, Futura Condensed ExtraBold. The testcase here has a very simple body style: body { font-family: Futura, sans-serif; } On 10.4 Futura maps to Futura Medium for normal body text. With h2 headings, the "larger, bolder" style maps to Futura Medium itself. On 10.5, Futura maps to Futura Condensed Medium for normal body text and the "larger, bolder" style maps to Futura Condensed ExtraBold. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102104 Minefield/3.0a9pre
Assignee | ||
Comment 14•16 years ago
|
||
I suspect this is related to bug 396002
Assignee: nobody → jdaggett
Assignee | ||
Comment 15•16 years ago
|
||
![]() |
||
Comment 16•16 years ago
|
||
On 10.4,. Futura doesn't ship with a bold face. And Gecko 1.9 Mac fails to create fake bolds in that case (bug 364713 covers that - bug 396002 targets some dfonts that do have the bold, according to the cocoa font panel in Textedit.app). Does Futura on 10.5 have a bold face in FontBook.app ? The use of Futura Condensed Medium for normal body text is a bug, I think. Your testcase with Arial gives the expected display on a system that has a 'black' face (= font-weight:900 according to the specs).
Assignee | ||
Comment 17•16 years ago
|
||
(In reply to comment #16) > On 10.4,. Futura doesn't ship with a bold face. And Gecko 1.9 Mac fails to > create fake bolds in that case (bug 364713 covers that - bug 396002 targets > some dfonts that do have the bold, according to the cocoa font panel in > Textedit.app). > > Does Futura on 10.5 have a bold face in FontBook.app ? Well, it sort of has a bold face, the "Futura Condensed ExtraBold". It's included in the .dfont file which is the same in both 10.4 and 10.5. > The use of Futura Condensed Medium for normal body text is a bug, I think. Yes, I think this is definitely a bug, probably a separate one from this original here. > Your testcase with Arial gives the expected display on a system that has a > 'black' face (= font-weight:900 according to the specs). I tracked this down, this is actually due to a font bug. The version of 'Arial Black' that ships with 10.4 has an incorrect weight specified in its OS/2 table. ftxdumperfuser -t 'OS/2' /Library/Fonts/Arial\ Black | grep usWeight returns <usWeightClass value="Normal" /> but with the version of 'Arial Black' that ships with 10.5, it returns: <usWeightClass value="Black" /> We could potentially add code that detects this one specific font bug, but that kinda sucks.
![]() |
||
Comment 18•16 years ago
|
||
(In reply to comment #17) > I tracked this down, this is actually due to a font bug. The version of 'Arial > Black' that ships with 10.4 has an incorrect weight specified in its OS/2 > table. (snipped) Aha... That makes this bug actually a 10.4 bug :-) Although in a way it is slightly surprising -but still within the rules for font-substitution in CSS- that the 'black' face would be chosen, when at OS level (and in TextEdit.app) it is treated as a completely separate font. The Arial installed in 'Classic' on PPC Macs also has the same bug, btw (not a surprise, it has the same version: 2.35). > We could potentially add code that detects this one specific font bug, but that > kinda sucks. ditto.
![]() |
||
Comment 19•16 years ago
|
||
The problem with Futura on 10.5 has been filed as bug 400717.
Assignee | ||
Comment 20•16 years ago
|
||
Name table info for 'Arial Black' from the previous seed build (9A559): <nameTableEntry nameTypeID="16" nameTypeName="PreferredFamily"> <localizedName platformID="1" platformName="Macintosh" scriptID="0" scriptName="Roman" languageID="0" languageName="English" isRawHex="NO">Arial</localizedName> </nameTableEntry> [ftxdumperfuser -t name /Library/Fonts/Arial\ Black.ttf] In the 10.5 GM build this entry, along with a separate entry for PreferredSubfamily, were removed. So the font system will treat Arial Black as a separate family (?!?). Since the Family setting (nameTypeID="1") is "Arial Black", this font will be treated as a separate family. Kinda sucky, but at least it will be consistent across 10.4 / 10.5 and Windows. As a general note, font designers do funky things with the family name. For example, DaiNippon Screen includes the family name "Hiragino Kaku Gothic Pro W3" along with "Hiragino Kaku Gothic Pro" in the list of family ID's. The W3 indicates the weight class and doesn't really belong as part of the family name, but, whatever... It would be nice to an explicit workaround to unify these fonts but my guess is that this would produce compatibility problems.
Assignee | ||
Comment 21•16 years ago
|
||
With the changes noted above, this bug no longer occurs in the 10.5 GM build.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in
before you can comment on or make changes to this bug.
Description
•