Uneven line-height for non-integer values

NEW
Assigned to

Status

()

Core
Layout: Text
P2
major
9 years ago
2 years ago

People

(Reporter: Jonas Wallden, Assigned: jtd, Mentored)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 327021 [details]
Test case
(Reporter)

Comment 2

9 years ago
Created attachment 327022 [details]
Screenshot comparing Safari 3.1 (left) and FF 3.0 (right)
(Reporter)

Updated

9 years ago
Component: General → Layout: Fonts and Text
Product: Firefox → Core

Comment 3

9 years ago
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.


QA Contact: general → layout.fonts-and-text
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 319724
Duplicate of this bug: 348908
Created attachment 327135 [details]
Screenshot of Testcase on IE, running in Vista VM
Created attachment 327136 [details]
Testcase running FF 3 on Vista VM

Comment 9

9 years ago
(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. 

Updated

9 years ago
Keywords: testcase

Comment 10

9 years ago
Created attachment 327173 [details]
testcase 2 (clearer result)

Shows the bug clearly on winXP

Comment 11

9 years ago
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

Updated

9 years ago
OS: Mac OS X → All
Hardware: Macintosh → All

Updated

7 years ago
Duplicate of this bug: 578615
(Assignee)

Comment 14

7 years ago
Better testcase from duplicate bug 578615:

https://bug578615.bugzilla.mozilla.org/attachment.cgi?id=578615
Assignee: nobody → jdaggett
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.

Comment 17

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

attachment 457271 [details]  (this link should work)
(Assignee)

Comment 18

7 years ago
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.

Comment 19

7 years ago
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!
(Assignee)

Updated

7 years ago
Severity: normal → major
Priority: -- → P2
Blocks: 610330

Updated

6 years ago
Duplicate of this bug: 707508

Comment 21

5 years ago
Still not fixed in 13.0, Ubuntu 12.04 amd64.

Comment 22

4 years ago
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.

Comment 23

3 years ago
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.
Flags: needinfo?(jdaggett)
Mentor: dbaron@dbaron.org
(Assignee)

Updated

2 years ago
Flags: needinfo?(jdaggett)

Comment 24

2 years ago
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.
You need to log in before you can comment on or make changes to this bug.