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.
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.
Line height is not exactly the same for all lines.
I would expect all lines to be identical for easier reading of long texts.
Created attachment 327021 [details]
Created attachment 327022 [details]
Screenshot comparing Safari 3.1 (left) and FF 3.0 (right)
Same on winXP. I suggest changing
Hardware/OS > All/All
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.
*** Bug 319724 has been marked as a duplicate of this bug. ***
*** Bug 348908 has been marked as a duplicate of this bug. ***
Created attachment 327135 [details]
Screenshot of Testcase on IE, running in Vista VM
Created attachment 327136 [details]
Testcase running FF 3 on 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.
Created attachment 327173 [details]
testcase 2 (clearer result)
Shows the bug clearly on winXP
Created attachment 327186 [details]
testcase 3 (best result)
Created attachment 327217 [details]
screenshot testcase 3, OS X
Gecko is on the left, WebKit on the right, OS X 10.5.3
*** Bug 578615 has been marked as a duplicate of this bug. ***
Better testcase from duplicate bug 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)
Created attachment 457497 [details]
testcase, vary line-height across non-integer em range
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!
*** Bug 707508 has been marked as a duplicate of this bug. ***
Still not fixed in 13.0, Ubuntu 12.04 amd64.
Created attachment 759835 [details]
Screenshot of ft article
The issue is still not fixed.
I've attached an example screenshot with selected lines
to highlight to problem.
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.