442139 - Uneven line-height for non-integer values (should round/snap line-height to device pixels)

Status: NEW

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

Description

[Jonas Wallden]

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.

Comment 1

[Jonas Wallden]

Attachment: Test case

Comment 2

[Jonas Wallden]

Attachment: Screenshot comparing Safari 3.1 (left) and FF 3.0 (right)

Comment 3

[j.j.]

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.

Comment 4

[Marcia Knous [:marcia]]

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.

Comment 7

[Marcia Knous [:marcia]]

Attachment: Screenshot of Testcase on IE, running in Vista VM

Comment 8

[Marcia Knous [:marcia]]

Attachment: Testcase running FF 3 on Vista VM

Comment 9

[j.j.]

(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. 

Comment 10

[j.j.]

Attachment: testcase 2 (clearer result)

Shows the bug clearly on winXP

Comment 11

[j.j.]

Attachment: testcase 3 (best result)

Comment 12

[philippe (part-time)]

Attachment: screenshot testcase 3, OS X

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

Comment 14

[John Daggett (:jtd)]

Better testcase from duplicate bug 578615:

https://bug578615.bugzilla.mozilla.org/attachment.cgi?id=578615

Comment 15

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

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)?

Comment 16

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

(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.

Comment 17

[j.j.]

(In reply to comment #14)
> Better testcase from duplicate bug 578615:

attachment 457271 [details]  (this link should work)

Comment 18

[John Daggett (:jtd)]

Attachment: 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.

Comment 19

[kyou]

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!

Comment 21

[madigens]

Still not fixed in 13.0, Ubuntu 12.04 amd64.

Comment 22

[Octoploid]

Attachment: Screenshot of ft article

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

Comment 23

[Elbart]

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.

Comment 24

[Ian Yang]

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.

Comment 25

[Pablo]

Hello

I know this is a very old issue, but I can still reproduce it on the latest Firefox versions (release, beta and nightly) using attachment " testcase 3 (best result) " on Windows 10, MacOS 11 and ubuntu 20.

so I'm going to mark it accordingly.

Comment 26

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 27

[j.j.]

Can we fix this please? We have CSS lh units now and it is inaccurate.

I made a small online tool to calculate some font metrics here:
http://jeka.info/test/font-metrics.html

Firefox gets line-height wrong due to this bug (as a strong assumption).

The tool probes the width of a 1lh wide element using getComputedStyle(element).width
I could fix my tool by using a huge font-size but ...