626946 - xkcd doesn't display menu and heading text correctly

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Ben Lerner]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 ID:20110110191547

See the screenshot.  This is a screenshot from a brand-new profile, compared to Chrome.   Weirdly, the text displays correctly in Safe mode, but not in normal mode.

Reproducible: Always

Comment 1

[Ben Lerner]

Attachment: Screenshot of Firefox in normal mode, vs Chrome.

Firefox in Safe mode displays like Chrome does...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Ben, what does that text look like in an IE9 beta?

What does it look like if you turn off hardware acceleration (or event just dwrite)?

Comment 3

[Ben Lerner]

Attachment: IE9 beta screenshot, for comparison

The IE9 beta is an odd mix: IE and Fx get the font boldness consistently right, as opposed to Chrome which has markedly heavier capital letters.  IE also gets the "XKCD updates..." line positioned right.  But it also cuts off the Archive/forums/... menu text.

For what it's worth, look at "html body div#container div#topContainer div#topLeft.dialog div.bd div.c div.s", which contains the ul with the Archive/Forums/New/Store/About menu.  All three browsers claim that that div measures 156x115px, with 16px padding and 0,8,0,4px margin.  That height is fixed by the stylesheet.

It seems to be a font-boldness issue: in Safe mode, Fx renders the text as in the Chrome screenshot, noticeably less bold than in normal mode (or IE, for that matter).  Given the boldness, it doesn't surprise me anymore than with a fixed 115px height, Fx can't help but cut off some text.  But why is Safe mode rendering text differently than normal mode?

How do I turn off hardware acceleration?  I tried the following (in case I guessed right):
* about:config, layers.accelerate-all = false, restart Fx and check
* about:config, layers.accelerate-none = true, restart Fx and check
Both times, it looked like the buggy rendering.

Comment 4

[Boris Zbarsky [:bzbarsky]]

What about setting gfx.font_rendering.directwrite.enabled to false?

Safe mode does turn off directwrite, as I recall, so I'm betting that'll make the rendering look like Chrome's again.  That changes the font metrics vs GDI, somewhat (and can change font selection).

That said, the difference vs IE9 is odd, since that also uses directwrite.  ccing some folks who might know what's going on there.

Comment 5

[Jonathan Kew [:jfkthame]]

The stylesheet on xkcd calls for sans-serif (which maps to Arial, by default) with font-weight:800, which is bolder than the "standard" Bold weight (700). Under GDI, this doesn't make any difference as only Regular and Bold weights are available; but the DirectWrite font APIs recognize the Arial Black face (weight 900, iirc) as a member of the Arial family, and therefore we are correctly choosing the Black face as per http://www.w3.org/TR/CSS2/fonts.html#font-boldness.

It's a mistake for the site to fix the size of the <div> so rigidly, and then use font specifications that may legitimately resolve to quite different faces depending on what's available on the user's system. It happens that Arial Black is not only considerably bolder than Arial Bold, it also has different line metrics. So it's not surprising the text doesn't fit in the fixed-size area provided.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Jonathan, the question I had is why the layout looks different in IE9.  Or is that not using the Black face in that screenshot for the text on the right?

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to comment #6)
> Jonathan, the question I had is why the layout looks different in IE9.  Or is
> that not using the Black face in that screenshot for the text on the right?

No, it's not using Black, it's using Bold. Presumably because there is no Black Italic face, so it gives priority to italic, and then picks the boldest available weight of the italic shape. Time to review the spec and see which is right here......

Comment 8

[Jonathan Kew [:jfkthame]]

Hmm, trying this myself on Win7, I get IE9-like behavior: Arial Bold Italic is used for the right-hand text.

Ben, do you by any chance have additional fonts installed on your system, including an Arial Black Italic (or Oblique) face?

Comment 9

[Ben Lerner]

I do, in fact.  Arial Regular, Italic, Bold, and Bold Italic; Arial Narrow, Narrow Italic, Narrow Bold and Narrow Bold Italic; and Arial Black and Black Italic.  I never gave much thought to Arial having multiple non-built-in weights; it's *Arial* after all ;-)

And I tested the IE9 beta on a different machine than I ran the Fx test on (don't have both browsers installed on both machines...) -- that could do it.

Comment 10

[Ben Lerner]

(In reply to comment #4)
gfx.font_rendering.directwrite.enabled was at its default value of false.  Toggling it to true didn't change anything.  However, toggling gfx.direct2d.disabled to true *did* change the rendering back to as it was in Safe mode.

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to comment #9)
> I do, in fact.  Arial Regular, Italic, Bold, and Bold Italic; Arial Narrow,
> Narrow Italic, Narrow Bold and Narrow Bold Italic; and Arial Black and Black
> Italic.

Aha! Ok, that explains it. In that case Firefox is correct to choose Arial Black Italic when the page requests sans-serif, italic, weight 800.

> And I tested the IE9 beta on a different machine than I ran the Fx test on
> (don't have both browsers installed on both machines...) -- that could do it.

Yes, indeed it could. If you're able to test both on the same machine (or ensure both machines have the same collection of Arial fonts installed), I expect sure you'll see the same behavior in both FF4 and IE9.

So this is a case of poorly-specified design. The simple solution would be for the stylesheet to use font weights of "normal" and "bold" (or 400 and 700), instead of the 500 and 800 that it currently has. It would also be wiser to use a less rigid layout - suppose the user's browser is configured so that "sans-serif" maps to a font with significantly different metrics from Helvetica or Arial.

Comment 12

[Jonathan Kew [:jfkthame]]

Resolving this as "invalid" - it's not a bug, it is correct behavior given the stylesheet being used and the collection of fonts available to the browser.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Reopening, and over to evangelism.  Can't have xkcd broken, so they need to fix.  ;)

Comment 14

[John Daggett (:jtd)]

One additional comment, testing with IE9 Beta won't have the same font matching as IE9 Final.  The beta used GDI font family groupings, later platform preview builds (e.g. Platform Preview 7) use DirectWrite font family groupings.  The site displays in Platform Preview 7 identically to FF4.

Comment 15

[Karl Dubost💡 :karlcow]

This seems to have been solved.