635640 - [DWrite] force font metrics of Arial Black to match the main Arial family

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Jonathan Kew [:jfkthame]]

Given how many pages we're seeing where design breaks down because people unexpectedly get Arial Black under DirectWrite (because of CSS that applies font-weight:bolder when the font is already bold, etc), I wonder if we should add a small hack to force the main font metrics of Arial Black to match those of the main Arial (Regular, Bold) faces.

This wouldn't alter the fact that people get a bolder face than they expected in these situations, but it could help to mitigate the impact on page design. Examples include the Archive button in GMail (see bug 589124) and the menu and heading text on xkcd.com (see bug 626946). IIRC, there have been a bunch of other similar bugs filed, and closed as dup or invalid.

I'm generally reluctant to hack around CSS/web-design mistakes, but in this case I'm beginning to think it might be worth doing. In some cases (e.g. see the xkcd.com example) the "problem" affects usability of the site, which means users will suffer, and relying on designers (who may not be using Windows with D2D/DW themselves) to realize and fix the problem may not be a sufficient answer.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: patch, force Arial Black font metrics to match Arial Bold

If we decide we want to do this, here's a possible approach - check in gfxDWriteFont::ComputeMetrics whether the face is Arial Black, and if so "borrow" metrics from Arial Bold instead (assuming it's available - if the rest of the Arial family is missing, we'll just proceed as normal).

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we're going to hack Arial, wouldn't it be better to simply treat Arial Black as not an Arial face, like GDI did? Then we'd avoid the "too bold" problem as well.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to comment #2)
> If we're going to hack Arial, wouldn't it be better to simply treat Arial Black
> as not an Arial face, like GDI did? Then we'd avoid the "too bold" problem as
> well.

We would, but I'd feel considerably worse about it as a hack! The suggestion here is basically to make Black's line-spacing match the rest of the family. Note that line spacing metrics are rather ill-specified anyway, with several different sets of metrics in OpenType fonts, and different applications/systems relying on different ones of them. So tinkering with them in the interest of consistency doesn't feel nearly as "wrong" as breaking up the family and failing to implement the CSS font-matching algorithm properly.

And getting the too-bold face doesn't usually cause serious disruption to sites; the more serious problems we've seen are generally due to the Black face having much larger line spacing. If we "fix" that, things may still not look quite like the designer expected but usability will not generally suffer.

The deeper answer is still for people to fix their sites, of course. We shouldn't let poor site design force us to stay compatible with past limitations forever, but the line-spacing issue is one compromise that I'm inclined towards making.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK

Comment 5

[John Daggett (:jtd)]

When using gmail, IE9 uses Arial Black for the 'Archive' button, just as we do.  But in the IE9 case, the height of the button is identical to other Arial text on that line.  Why are their metrics different from those of FF4?

Comment 6

[John Daggett (:jtd)]

I'm actually not so keen about this approach, I don't think we should be working around problems that are fundamentally problems of faulty CSS design.  I'm more concerned as to why our metrics are different than IE9's, not just in the case of Arial vs. Arial Black but in other cases also.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to comment #5)
> When using gmail, IE9 uses Arial Black for the 'Archive' button, just as we do.
>  But in the IE9 case, the height of the button is identical to other Arial text
> on that line.  Why are their metrics different from those of FF4?

It's interesting to note that until very recently - late Platform Preview, at least - IE9 showed the same issue with the metrics of Arial Black; the GMail archive button rendered substantially taller than its neighbors, for example. They seem to have changed this in IE9RC, which I suspect means they may have decided to apply a similar "harmonization" of the metrics across the Arial family - seeing this was one of the things that prompted me to consider doing the same in Gecko.

(In reply to comment #6)
> I'm actually not so keen about this approach, I don't think we should be
> working around problems that are fundamentally problems of faulty CSS design. 

I generally agree with this - which is why I wouldn't be in favor of "removing" Arial Black from the Arial family, so that people don't start seeing Black on pages that used to render Bold. But the discrepancy in line-spacing metrics between Regular/Bold and Black could be regarded as an anomaly in the font collection, so that the resulting layout problems are as much due to the poorly-coordinated fonts in the family as to poor CSS design. As such, I think this is on a similar level to the Gill Sans / Gill Sans MT "hack" that was added in bug 551313.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: patch, v1.1 - make Arial Black vertical metrics match the rest of Arial family - tidied up code

Tidied up the patch a bit, asking for review; then we'll have to face the question of whether to do this for FF4.0.

We need to decide if this is something we want to do, in order to reduce disruption to real-world sites that expect the line-spacing metrics of Arial to stay the same regardless of font-weight, or whether we're going to stick to the line that it's entirely the sites' problem and our behavior is correct in view of the metrics in the Black font.

Personally, although I dislike "hacks" like this, I'm inclined to favor doing it, as discussed in comments above.

If we _are_ going to do this, we should do it before FF4.0 ships, rather than in a subsequent update/version. So we need to decide one way or the other.

Comment 9

[Bas Schouten (:bas.schouten)]

Comment on attachment 515691 [details] [diff] [review]
patch, v1.1 - make Arial Black vertical metrics match the rest of Arial family - tidied up code

The code looks fine. I'll leave the decision of whether we should do this to others :)

Comment 10

[Jonathan Kew [:jfkthame]]

Comment on attachment 515691 [details] [diff] [review]
patch, v1.1 - make Arial Black vertical metrics match the rest of Arial family - tidied up code

Requesting approval-2.0. See comments for discussion of pros and cons. The patch itself carries minimal risk; the decision needed is whether we want to stick to a "purist" position and leave web authors to fix the CSS issues, or apply a pragmatic fix to make things work better for (Windows/D2D) users on current real-world sites.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 515691 [details] [diff] [review]
patch, v1.1 - make Arial Black vertical metrics match the rest of Arial family - tidied up code

a- for now

Without screenshots showing the before/after on sites like xkcd and other affected sites, I don't think we can reason about the *correctness* of this fix, which is required for deciding about approval.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, I'm generally against doing hacks like this, though I could be convinced in specific cases.

Is Windows the only platform that ships Arial or Helvetica in more than two weights?  Or are pages using font-family: Helvetica, Arial going to end up with a 900 weight Helvetica in the same situation on Mac?

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: screenshot showing GMail and xkcd without the Arial-hack patch

Comment 14

[Jonathan Kew [:jfkthame]]

Attachment: screenshot showing GMail and xkcd with the Arial-hack patch

Note how the patch solves the problem of the Archive button size in GMail, and the site menu on the left in xkcd. The text is still rendered in Arial Black, but vertical metrics/positioning are not disrupted.

Comment 15

[Joe Drew (not getting mail)]

Ah. We were confused and thought that horizontal metrics would change, but only the vertical metrics change.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to comment #12)
> FWIW, I'm generally against doing hacks like this, though I could be convinced
> in specific cases.

Me too, as a general rule.

> Is Windows the only platform that ships Arial or Helvetica in more than two
> weights?

AFAIK, yes. OS X ships Arial Black but not as part of the Arial family (so it's like GDI in that regard, even though in principle it's not bound by the same limitations.

>  Or are pages using font-family: Helvetica, Arial going to end up with
> a 900 weight Helvetica in the same situation on Mac?

OS X does ship Helvetica Neue with multiple weights, but the Black weight is only present in Condensed, not regular width. But also note that the line-spacing metrics do _not_ vary across weights as in the Arial/Arial Black case. The Ultralight face seems to have slightly tighter metrics than the rest of the weights, but otherwise they're consistent right across the range.

(My guess is that the discrepancy between Arial Black metrics and the rest of the family is not a deliberate design choice, but an accident of provenance; the Black face was created separately from the others, and nobody thought to compare and harmonize the line metrics. This suspicion is supported by the fact that several of the strings in the font metadata have slightly different forms (company name, authors, file description, license description), suggesting they originated at different times in the company's history. This is a factor - besides simply making things better for users - that IMO weighs in favor of the "hack" that harmonizes the line metrics we use; I think we're not overriding a designer's deliberate choice but fixing up an accidental mismatch.)

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 515691 [details] [diff] [review]
patch, v1.1 - make Arial Black vertical metrics match the rest of Arial family - tidied up code

I don't think that we want to do this so late in the game for Firefox 4. My actual opinion is that we should WONTFIX.

Comment 18

[(no longer active)]

http://hg.mozilla.org/projects/cedar/rev/ddc36fce0c76

Comment 19

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/ddc36fce0c76