[10.5] Font handling picks up a new bold font; causes page layout issues

VERIFIED WORKSFORME

Status

()

defect
VERIFIED WORKSFORME
12 years ago
12 years ago

People

(Reporter: samuel.sidler+old, Assigned: jtd)

Tracking

({regression, testcase})

Trunk
PowerPC
macOS
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(7 attachments)

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?
Posted file Testcase
Whoops. Forgot to attach the testcase. :-/
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.

Comment 3

12 years ago
this is 10.5 only?
The font looks fine to me running 10.4.10, so I would say this is only a 10.5 issue.
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;}
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.
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.
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 ?
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.
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 13

12 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

12 years ago
I suspect this is related to bug 396002
Assignee: nobody → jdaggett
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

12 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.
(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.


The problem with Futura on 10.5 has been filed as bug 400717.
Assignee

Comment 20

12 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

12 years ago
With the changes noted above, this bug no longer occurs in the 10.5 GM build.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.