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

Status: VERIFIED WORKSFORME

(Core :: Graphics, defect)

Description

[Samuel Sidler (old account; do not CC)]

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.

Comment 1

[Samuel Sidler (old account; do not CC)]

Attachment: Testcase

Whoops. Forgot to attach the testcase. :-/

Comment 2

[Samuel Sidler (old account; do not CC)]

Attachment: Screenshot of 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

[Stuart Parmenter]

this is 10.5 only?

Comment 4

[Marcia Knous [:marcia]]

The font looks fine to me running 10.4.10, so I would say this is only a 10.5 issue.

Comment 5

[philippe (part-time)]

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

[philippe (part-time)]

Attachment: test case with 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.

Comment 7

[Samuel Sidler (old account; do not CC)]

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

[philippe (part-time)]

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

[Marcia Knous [:marcia]]

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.

Comment 10

[Samuel Sidler (old account; do not CC)]

Yeah, as I stated in comment 2, this doesn't happen on branch, only trunk.

Comment 11

[John Daggett (:jtd)]

Attachment: comparison of Arial font weights, 10.4 vs. 10.5 9A559

Comment 12

[John Daggett (:jtd)]

Attachment: testcase for rendering text with weights 100 - 900

Comment 13

[John Daggett (:jtd)]

Attachment: Futura text and headers use different fonts 10.4 vs 10.5

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

Comment 14

[John Daggett (:jtd)]

I suspect this is related to bug 396002

Comment 15

[John Daggett (:jtd)]

Attachment: Testcase for Futura text and headings

Comment 16

[philippe (part-time)]

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).

Comment 17

[John Daggett (:jtd)]

(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

[philippe (part-time)]

(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

[philippe (part-time)]

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

Comment 20

[John Daggett (:jtd)]

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.

Comment 21

[John Daggett (:jtd)]

With the changes noted above, this bug no longer occurs in the 10.5 GM build.