643781 - Increased line heights with DirectWrite (unlike in IE9)

Status: NEW

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

Description

[Dão Gottwald [:dao]]

Attachment: testcase

Line heights are often larger when using hardware acceleration, letting Firefox be the odd one out. This seems like a significant obstacle for web designers. All other browsers seem to use consistent vertical metrics, including hardware-accelerated IE9.

Comment 1

[Dão Gottwald [:dao]]

Attachment: screenshots: Firefox with HW accel on / off / IE9 with HW accel on

Comment 2

[Matthieu Rivaud]

FWIW, this has already been discussed in bugs #601152 and #628601. I think it would be better to mimic IE9 behaviour here and compensate, but I wholeheartedly agree that no web developer should rely on fixed/consistent font-metrics across platforms (and this is without taking font install base discrepancies into account) ...

Comment 3

[Karl Tomlinson (:karlt)]

Reading http://msdn.microsoft.com/en-us/library/dd368074%28v=vs.85%29.aspx
and gfxDWriteFont::ComputeMetrics() leaves me a little confused.

The descriptions of DWRITE_FONT_METRICS::ascent/descent/lineGap make them sound like TypoAscender/TypoDescender/TypoLineGap in the OS/2 table.
http://www.microsoft.com/typography/otspec/os2.htm

If that is the case, the line heights calculated in gfxDWriteFont::ComputeMetrics() should be <= those calculated for a gfxGDIFont
(in the limit as size increases - see below).

However, gfxDWriteFont assigns the DWRITE_FONT_METRICS::ascent/descent (values that I would expect to closely correspond to gfxFont::Metrics::emAscent/emDescent) to gfxFont::Metrics::maxAscent/maxDescent, values to which gfxGDIFont has historically assigned WinAscent/WinDescent.
(This should not affect line-height; it just makes me wonder which metrics these DWRITE_FONT_METRICS really are.)

The other key difference is that gfxDWriteFont rounds *up* each of maxAscent/maxDescent/externalLeading (independently), which could increase line height by up to 3 pixels, depending on exactly what formula GDI used.
Does the difference reduce at larger font sizes?

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> The other key difference is that gfxDWriteFont rounds *up* each of
> maxAscent/maxDescent/externalLeading (independently), which could increase line
> height by up to 3 pixels, depending on exactly what formula GDI used.
> Does the difference reduce at larger font sizes?

I changed the font size from 20 to 50, the difference in height of the colored boxes remains 2px.

Comment 5

[Steven Hartland]

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

This really needs fixing, you cant expect designers to specify a line-height for every single use of font-size :(

Comment 6

[Boris Zbarsky [:bzbarsky]]

Uh... why do they need to specify a line-height at all?

Comment 7

[Dão Gottwald [:dao]]

They wouldn't normally specify a line-height; doing so is the obvious workaround for this bug.

Comment 8

[Steven Hartland]

Could this be done in the useragent css making it compatible with previous versions?

Comment 9

[Boris Zbarsky [:bzbarsky]]

No.  The UA style is "line-height: normal"; the exact ratio of line-height to font-size then depends on the font in use.

Comment 10

[Steven Hartland]

But that's exactly the point its not based on the font, its based on the font + render and as the renderer has been changed its caused this issue, the font is not changing here.

Not sure if its feasible / practical / workable but something like "normal" = 1.1em or something like that then at least its predictable, which is the main issue.

Comment 11

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

Is this only an issue with 'line-height: normal', or is there also a difference between GDI and DirectWrite with line-height: 1.2 or 1.0?

Also, which of the GDI or DirectWrite behavior is more similar to what happens on other platforms (using the same font)?

Comment 12

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

(discussed in triage meeting)

This is something we shipped in 4, and I don't see enough here to say that we wouldn't pull from aurora to beta without a fix for this.

But more data (e.g., answers to my previous comment) might change that.  Please renominate if you think there's information that should cause us to reconsider.

Comment 13

[Alex]

It's only an issue with line-height: normal, every other value is consistent (Doesn't line-height use font-size for it's measurement? so "normal" would use the font metrics but any other value will be a multiple of the specified font-size?)

And the rendering with DirectWrite matches the rendering on OS X at least, so this has always been "broken" in that regard.

Comment 14

[Karl Tomlinson (:karlt)]

Regressed
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=523d0f8e0926&tochange=6bdb8153b671

Most likely the rounding changes in
http://hg.mozilla.org/mozilla-central/rev/4365eabf7fb0

Comment 15

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> The descriptions of DWRITE_FONT_METRICS::ascent/descent/lineGap make them
> sound like TypoAscender/TypoDescender/TypoLineGap in the OS/2 table.
> http://www.microsoft.com/typography/otspec/os2.htm

They only reflect OS/2 typo metrics when the USE_TYPO_METRICS bit in fsSelection is set to say "it is strongly recommended to use OS/2.sTypoAscender - OS/2.sTypoDescender+ OS/2.sTypoLineGap as a value for default line spacing for this font."
http://www.microsoft.com/typography/otspec/os2.htm#fss

When that bit is not set (and it is not set for Tahoma) DWrite seems to be using a legacy compatibility mode where ascent and descent come from winAscent/winDescent (same as GDI) and line height comes from the hhea metrics, apparently applying a minimum of 0 to lineGap (consistent with GDI).

Comment 16

[Karl Tomlinson (:karlt)]

I added a patch to bug 657864 to correct rounding when the line-height comes from the font line-height metrics.  That doesn't help this bug because the line-height comes from the ascent and descent metrics.

I see two possible ways to fix this bug:

1. Round maxAscent/Descent to nearest pixel (instead of rounding up), or

2. Let the line-height be smaller than maxAscent + maxDescent.

   To avoid regressing bug 548964, ComputeDescentLimitForSelectionUnderline
   should be modified to limit to the line-height rather than the maxDescent.
   http://hg.mozilla.org/mozilla-central/annotate/eb3239a968ac/layout/generic/nsTextFrameThebes.cpp#l4449

Both approaches are quite reasonable in my opinion.
A possible complication with approach 1 is that some overflow of glyphs outside the ascent/descent may cause rendering turds.  (The overloading of layout metrics and glyph bounding boxes is unfortunate.)

I've spent more time on this than expected, which is more than I should right now, so I may not get back to this soon.

Comment 17

[Karl Tomlinson (:karlt)]

Our quirky behavior (even when not in quirks mode) where line-heights are increased to maxAscent + maxDescent (only) when line-height is "normal" may cause problems for text areas when they calculate their height from a line-height is less than maxAscent + maxDescent.

http://hg.mozilla.org/mozilla-central/annotate/f5dbf215f9ea/layout/generic/nsLineLayout.cpp#l1954

Comment 18

[Karl Tomlinson (:karlt)]

I expect we could safely round maxAscent/Descent to nearest when it is greater than the line-height (which would show as zero lineGap in DWRITE_FONT_METRICS).
In this situation, ascent/descent most likely come from winAscent/winDescent, which is often overly generous.

We could continue to round up when maxAscent + maxDescent is less than the line height.  In this situation ascent/descent most likely come from typo metrics and could do with a bit of padding to include taller glyphs and to make text selection backgrounds and caret appear as expected.

Comment 19

[Steve White]

Hi Karl et al.

I don't quite understand some of your remarks here, but they are familiar.  Let me put in my 2 cents.

Do not do any calculation of line height and spacing based on the placement of glyphs in the font (or maxAscent/maxDescent).  It is purely wrong to do so: you will screw up display of many fonts that way.  (If you're worried about ****, clip -- dont' mess with metrics.)

The font designer has the metrics and (perhaps naïvely) expects them to be adhered to.

The 'OS/2' usWinAscent/usWinDescent describe *clipping* regions (see the TrueType Reference Manual).  They ought not to have anything to do with line height.  This is made very clear in the OpenType specs.

The disparity between the specs and the usual implementation, especially on Windows, is an old problem.  Unfortunately on Windows, many apps take the usWin* metrics as line height metrics.  As you pointed out, the USE_TYPO_METRICS bit was intended to resolve this: if that is set, there should be no question.  The line height and clipping regions are clear.

In case USE_TYPO_METRICS isn't set, and the other metrics are inconsistent, there are various ad-hoc recommendations.  It's unfortunate.

In no case use should the positions of the glyphs in the font be consulted in these calculations, however.

Comment 20

[Jonathan Kew [:jfkthame]]

Attachment: use more consistent and properly-rounded line-height metrics for GDI and Mac font backends.

This is based on the WIP patch from bug 598900. It switches us to using the same 'sfnt' metrics (where available) on GDI and Mac, and incorporates similar rounding to the DWrite patch. With this, the line-height test works consistently across platforms, and the Cambria Math problem from bug 598900 is also resolved.

Comment 21

[Jonathan Kew [:jfkthame]]

Comment on attachment 8369396 [details] [diff] [review]
use more consistent and properly-rounded line-height metrics for GDI and Mac font backends.

Oops, wrong bug - meant to attach that patch to 657864.

Comment 22

[Jonathan Kew [:jfkthame]]

Attachment: be more careful about rounding metrics so as to preserve line-heights * *

Here's the DWrite patch, rebased to trunk; this is the only piece relevant to Win8/Metro.

Comment 23

[Jonathan Kew [:jfkthame]]

Comment on attachment 8369403 [details] [diff] [review]
be more careful about rounding metrics so as to preserve line-heights  * *

Wrong again :( - moved to bug 657864.

Comment 25

[Elbart]

I just wanted to note that DirectWrite is currently set to be enabled by default in Chrome 37[1], and so far it doesn't show the same line-height issues as Firefox.
At least I haven't noticed any problems on sites and testcases which are problematic with Firefox.

[1] http://www.chromestatus.com/features/4725550652325888

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 31

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.