567466 - Font spacing different with d2d on vs off

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Daniel Kirsch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100521 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100521 Minefield/3.7a5pre

When enabling DirectWrite font spacing is changing - especially for numbers.
See http://klotzen-statt-kleckern.de/bugzilla/dw_textzoom.html for an example showing two screenshots. One with d2d enabled and one disabled. Click the page to toggle the view. Take a look at the bug 567410 tab and it's label.

Reproducible: Always

Comment 1

[Daniel Kirsch]

Attachment: HTML text example d2d OFF

The screenshot was made with a simple html document containing text with no style definition. d2d was disabled.

Comment 2

[Daniel Kirsch]

Attachment: HTML text example d2d ON

This screenshot shows the same page with d2d enabled.

The example shows that not only the XUL GUI is affected but also html documents and in this case especially the letters look different.

Comment 3

[Daniel Kirsch]

A direct comparison between the two screenshots can be found at http://klotzen-statt-kleckern.de/bugzilla/dw_textspacing.html

Comment 4

[Daniel Kirsch]

Besides the difference in letter spacing there also seems to be a different line height.

Comment 5

[Daniel Kirsch]

IMHO the difference in letter spacing and line height causes the different html page layout when using textzoom as seen in from http://klotzen-statt-kleckern.de/bugzilla/dw_textzoom.html

Reminder for myself: If this bug get's fixed, check text zoom again.

Comment 6

[Bas Schouten (:bas.schouten)]

To some extent this is expected. Similarly font spacing is different across platforms. This is simply the first time we've had different font backends on a single platform. To be clear, DirectWrite is not -ment- to look the same as GDI, as GDI in many cases performs very poorly (for example, resize a window and see how letters 'dance' around due to pixel snapping), it's ment to look better though. In cases where it significantly looks worse we should see if there's something we can do.

DirectWrite will very likely show off poor page design though (where designs are based on certain font spacing expectations, when those expectations only 'happen' to be true for certain GDI fonts)

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

In this particular case though, it makes the text look worse...

Comment 8

[Bas Schouten (:bas.schouten)]

Hrm, personally I prefer the DWrite glyph rendering for sure (notice the emphasis on the horizontal lines on the 2 and the 7 in GDI). For the spacing, I kind of prefer the DWrite version but I can certainly see why someone would like the GDI tighter packing.

Comment 9

[Daniel Kirsch]

I like the new rendering. Text looks smooth without getting too blury or bold. I see more details especially for serif types (see the "t" in the example from comment 3) and the increased letter spacing makes it easier to read - especially for smaller font sizes.

But the difference between the text with DWrite enabled to disabled is around 9% (181px versus 197px). IMHO this is a huge difference and will break a lot of layouts (badly designed or not). It will definitely cause text to wrap at a different position which could then cause more text lines.
Current font rendering is nearly identical between the major browsers at least for the letter spacing. When setting line-height explicitly to a px value this is also true for line-height.

We create browser based software simulations which need to look identical at least in IE and FF because very often objects need to be placed at an exact position. We reached a good level here (with some workarounds especially for IE) but this bug would definitely make live very hard and break some apps.
Line height MUST be identical to non DWrite layout and the difference in letter spacing should at least be less than 9%.

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to comment #9)
> We create browser based software simulations which need to look identical at
> least in IE and FF because very often objects need to be placed at an exact
> position. We reached a good level here (with some workarounds especially for
> IE) but this bug would definitely make live very hard and break some apps.
> Line height MUST be identical to non DWrite layout and the difference in letter
> spacing should at least be less than 9%.

It's fairly easily done, we can simply set a flag and DWrite will space identically to GDI. We'll loose some subpixel positioning and other goodness :) And that's how backward compatibility breaks progress.

But, yes, 9% is surprisingly much, we should make sure the same font is being used and we're not doing something else wrong. Also there might be a flag which renders more like GDI, but still somewhat better.

Comment 11

[John Daggett (:jtd)]

Attachment: testcase, simple text using Times New Roman

Testcase to duplicate the screenshot text

Comment 12

[John Daggett (:jtd)]

I think this is actually not a bug, it's simply the difference in Cleartype vs. DirectWrite text rendering.  Look at the text waterfalls here:

http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls-default.html

With DWrite enabled, text is rendered consistently across a range of sizes.  Without DWrite , Cleartype/Uniscribe/GDI rendering is somewhat odd, it jumps in strange increments.  Note how for Georgia the text spacing doesn't change between 11 and 12px, even though the glyphs are bigger!

This is a tradeoff between text fidelity and sharpness.  The DWrite text is more evenly spaced across sizes but the anti-aliasing involved means a lighter appearance and greater fuzziness.  Cleartype rendering emphasizes clean verticals by jiggling the spacing in ways that make it appear unbalanced at some sizes.

Comment 13

[John Daggett (:jtd)]

Attachment: screenshot, Times New Roman waterfall, DWrite vs. Cleartype GDI

Left is Minefield with DirectWrite enabled, right is Chrome (same as FF w/o DirectWrite enabled)

Comment 14

[John Daggett (:jtd)]

Attachment: screenshot, Georgia waterfall, DWrite vs. Cleartype GDI

Comment 15

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

Pages that are broken with DirectWrite are likely already broken on Mac and probably Linux.

For people who want pixel-accurate layouts across browsers, could there be fonts whose horizontal metrics are tuned to fixed integer values at various sizes? Then you could use those fonts using CSS @font-face and everyone would be happy.

As a last resort I suppose we could have a new text-rendering CSS value that triggers GDI mode on Windows. That would yucky though.

Comment 16

[Jonathan Kew [:jfkthame]]

Attachment: screenshot of Arial waterfall in IE9 platform preview

I agree that this is a feature, not a bug. For an additional comparison, note that IE9 Platform Preview also gives smoothly-changing glyph spacing (i.e. using subpixel positioning).