628601 - Line spacing problem with D2D enabled(use hardware acceleration when available)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[zgf1]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110114 Firefox/4.0b10pre
Build Identifier: 4.0b10pre

Firefox4 d2d on(use hardware acceleration when available - on):
http://zgf1.e-net24.pl/screensender/img/img_22877999.png

Firefox4 d2d off(use hardware acceleration when available - off):
http://zgf1.e-net24.pl/screensender/img/img_22905408.png

Reproducible: Always

Steps to Reproduce:
1. go to http://www.benchmark.pl/
2. enable-disable hardware acceleration
3.

Comment 1

[Jonathan Kew [:jfkthame]]

This site uses rigid CSS formatting with fixed-size <div> elements, which assume certain font metrics. I see similar clipping issues in FF3.6 on OS X, for example, because the font metrics on OS X are not the same as the (Windows-using) designer assumed.

The fact that DirectWrite (used when D2D is on) and GDI (used by default when D2D is off) give somewhat different font metrics, leading to different character and line spacing, is not a bug. Sites should not be assuming that metrics will remain exactly the same across different systems and platforms.

Comment 2

[Matthieu Rivaud]

FWIW, IE9 seems to compensate for these discrepancies in font metrics (at least for line height) ...

Comment 3

[Steven Hartland]

Yes this is a major issue, messing with all sites that don't explicitly set a line height for everything!

Saying that metrics shouldn't be assumed across different systems and platforms is quite frankly a massive cop-out, are your seriously expecting developers to set a line-height for every single element? Meaning you cant use font-size without a corresponding line-height entry I mean seriously?

Firefox 3.x, Chrome, IE, Safari all render pages the same, only Firefox 4 with hardware acceleration causes issues.

As an example in our page we had a font-size of 14px which results in a line-height of 16px with HW Accel on and 14.4px with HW Accel off over a even a paragraph of text that's a massive difference.

Already causing issues for users:-
http://support.mozilla.com/sv-SE/questions/782490

Related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=643781

Comment 4

[Boris Zbarsky [:bzbarsky]]

> As an example in our page we had a font-size of 14px which results in a
> line-height of 16px with HW Accel on and 14.4px with HW Accel off 

What what line-height does it end up with on Mac?  What about on Linux?  What about if the fonts you specified are not installed?  What about when the user has set a minimal font size of 16px because they can't read your tiny 14px font?

If you're depending on a particular line-height, your site is just broken, sorry.  We should consider working around the brokenness, but saying it's broken is very much not a cop-out.

Comment 5

[Steven Hartland]

No because if you have specified a font-size then it makes sense from a designers perspective that line-height is based off that, randomly changing it based on a browser option is very much unexpected behaviour.

Every main stream browser including Mac and linux looks very much the same, only FF4 is significantly different and only with HW Accel enabled; surely that and that alone is enough to mean it should be updated to make it more compatible?

People can procrastinate about you need to set line-height all they want but that won't make it any less of an issue in the real world.

From a dev perspective sure you can say its not out of spec, but doesn't make it right. At what point in the html spec did they document that when setting font-size you MUST also set line-height to make a block of text look remotely the same with regards vertical height?

The most relevant part of the spec in my mind is "We recommend a used value for 'normal' between 1.0 to 1.2." currently FF4 appears to be using ~1.02 when HW Accel is disabled and ~1.145 when its enabled. That's quite a difference across even just paragraph of text.

The most important issue here is in its current implementation FF4 is not backwards compatible or even comparible with other browsers. A page which looks the same in FF 2.x - 3.6 and all other browsers looks significantly different in FF 4 due to this. That's what makes it a problem in the real world.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Steven, the line-height is based on the font _metrics_, which depend on the font size.  It's not directly based on the font size.  Different fonts will have very different line-heights at the same font-size.  The same font can have a different line-height depending on the exact positioning of the glyphs by the rasterizer.

> Every main stream browser including Mac and linux looks very much the same,

That's just not the case, sorry.  As someone who's been using Mac and Linux browsers for about 15 years now, it's pretty common to have sites that assume Windows font metrics and design around them, then break on Mac and Linux.  That doesn't mean that font rendering on Mac and Linux is broken; it means the sites are broken.

> but doesn't make it right.

The issue in this case is not that of "spec" but that of us asking the OS to render the font for us and it telling us how much line spacing that needs.  Then we use that amount of spacing.  That's all that's going on here.

> The most relevant part of the spec in my mind is "We recommend a used value
> for 'normal' between 1.0 to 1.2." 

That's the part that means you can't rely on heights being anything in particular unless you set line-height yes.

You also can't rely on heights being anything in particular unless you set the glyph advance of every glyph, the kerning of all kerning pairs, all ligature settings, and the exact algorithm for subpixel positioning and antialiasing of text, because vertical height depends on line-break positions, which depend on the _width_ of the text, which depends on all of the above things.  Which is why sites break on Mac and Linux all the time wrt heights; they assume that for a given width they'll have some fixed number of lines of text in the block, and turn out to be wrong.

Seriously, if you think you can control the height of a block of text that just means you're not testing on a wide enough range of systems...

> currently FF4 appears to be using ~1.02 when HW Accel is disabled and ~1.145
> when its enabled. 

Again, the exact number depends on the font and the metrics it specifies, as reported by the operating system.

I agree there is a real-world problem here due to the prevalence of poorly-authored sites that make invalid assumptions.  We may need to add a work-around for these sites.  But I just want you to be under no illusions about the fact that the sites _are_ broken, and a workaround for D2D in particular won't fix their brokenness with other font rendering systems.  It'll just hide the problem from the site authors and hurt non-Windows users.

Comment 7

[Steven Hartland]

Yes quite well aware of how the details are determined, fonts and all the internals are very complicated and the real cause is the spec or the lack of it e.g. this would have been a none issue if there was a fix line-height based on font-size by default, but its not quite that simple.

Designers "should" really be able to rely on relatively standard behaviour for a given font + size. In general they are aware of slight differences for users that don't have font's on other OS's which is why they specify fall backs and test.

All in all I agree with you, but as said before doesn't mean its not a problem ;-)

Comment 8

[Boris Zbarsky [:bzbarsky]]

> if there was a fix line-height based on font-size by default

Then some fonts would be wholly unreadable.  You can't use the same line-height for a handwriting-like font with large loopy ascenders/descenders everywhere and for Times New Roman at the same font-size without either having the former overlap all over or having the latter look ridiculous...

> for a given font + size.

Well... the problem is that what CSS lets designers specify is a font _name_ which might be quite different fonts for different users even without any fallback happening.  Downloadable fonts aside, of course.

Comment 9

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It's still occurring ?
I see that benchamrk.pl made some changes on their site, so maybe it's "fixed"

Comment 10

[Steven Hartland]

The following bug stops designers affected by this bug fixing it using css for the effected elements:-
https://bugzilla.mozilla.org/show_bug.cgi?id=349259

Comment 11

[Karl Dubost💡 :karlcow]

RESOLVED as Worksforme.
Reopen if you think there is still an issue.

Comment 12

[Elbart]

THere are still differences between hwa on and off, i.e. the height of the pagination-boxes in the middle-section; the vertical positioning of the labels in the navbar and of the text in the right captions ("Aktualności") and in the "Zaloguj"-button; the thickness of the bullet-points under "Aktualności".