User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/527+ (KHTML, like Gecko) Version/3.1.1 Safari/525.18 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 When line-height is a fractional value the resulting text will get inconsistent line spacing. Even though it is mathematically correct to distribute the rounding error over subsequent lines the resulting text rendering is far more unpleasant to read. I'll attach an example and a screenshot comparing FF 3.0 and Safari 3.1. Reproducible: Always Steps to Reproduce: 1. Set a non-integer line-height manually or let it be computed as a percentage of the font size. 2. Render multiple lines of text. Actual Results: Line height is not exactly the same for all lines. Expected Results: I would expect all lines to be identical for easier reading of long texts.

Same on winXP. I suggest changing Hardware/OS > All/All Keywords: testcase This was reported several times, but unfortunately never left the "unconfirmed" state. See bug 319724 or bug 348908.

Confirming on Mac, as I see this using the testcase in the bug running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0. However, contrary to what is reported in Comment 3, I do not see the issue running FF in a Vista VM.

(In reply to comment #4) However, contrary to what is reported in Comment 3, I do not see > the issue running FF in a Vista VM. Hmm, if I look closely at attachment 327136 [details] (Vista screenshot), I'd say the spacees are a bit wider between lines 2-3, 5-6, 7-8, 10-11, 12-13, 15-16, 17-18 On my system (winXP) the result is the same, but seems more obvious.

Shows the bug clearly on winXP

Gecko is on the left, WebKit on the right, OS X 10.5.3

Better testcase from duplicate bug 578615: https://bug578615.bugzilla.mozilla.org/attachment.cgi?id=578615

Are you planning to change line-height so it's handled like border widths? That would make sense. Should what we do here depend on whether the underlying platform supports subpixel vertical positioning of text (Windows with D2D does, I think)?

(In reply to comment #15) > Are you planning to change line-height so it's handled like border widths? > That would make sense. Yes, I think that's a great idea. > Should what we do here depend on whether the underlying platform supports > subpixel vertical positioning of text (Windows with D2D does, I think)? If we want to use subpixel vertical positioning then we'd have to disable the rounding of text baselines that we do in nsCSSRendering and nsTextFrame. However, I wonder if DirectWrite's vertical subpixel positioning is good enough to make unaligned baselines look good in all cases.

(In reply to comment #14) > Better testcase from duplicate bug 578615: attachment 457271 [details] (this link should work)

Extending previous testcase to include computed line-height value and an overlay showing an absolutely positioned div to simulate the effect of using an image sized in em's. Space to start/stop iteration, up/down arrows to vary line-height manually.

The bug is not yet fixed in Firefox 4.0 beta 6. It’s so ugly, but seems to be on the bottom of the priority list! Please fix this bug!

Still not fixed in 13.0, Ubuntu 12.04 amd64.

The issue is still not fixed. I've attached an example screenshot with selected lines to highlight to problem.

Another example: https://crash-stats.mozilla.com/report/index/0da00c62-0a3f-4482-9675-5772e2141026#rawdump Search for _call and keep enter pressed to cycle through all the results and enjoy funky line-dancing. The culprit is line-height:1.7, which calculates to 20.4px. Happening in Windows with and without HWA, and in Ubuntu with the latest release-version.

As a web developer, I sincerely hope this bug be fixed as soon as possible so that I would no longer have to write additional CSS just for fixing Firefox's rendering.