Closed Bug 1428826 Opened 6 years ago Closed 6 years ago

Font rendering regression on Ubuntu 16.04


(Core :: Graphics: Text, defect, P3)




Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- fixed


(Reporter: gcp, Assigned: jfkthame)



(Keywords: regression, Whiteboard: [gfx-noted])


(5 files)

A recent change to Nightly has significantly changed how fonts are rendered on my Ubuntu 16.04 LTS installation.

A likely culprit is bug 1427641.

Of course any change to font rendering - even if not necessarily worse - is going to look strange at first. But there are a few strange things, such as UI fonts changing (which sounds odd given the patch description). And in general fonts appear harder to read. I think I can demonstrate why with the attached screenshot.

Not the kerning for combinations as "(Wi)ndow". The spacing is very small now, and this makes things harder to read. IMHO it's even worse with some other fonts (such as IRCCloud "legacy") but I took this one as it's in our core UI and I think wouldn't be expected to change the underlying font.
Blocks: 1427641
Yes, I agree that doesn't look good, and bug 1427641 (specifically, patch 1 there) is pretty much sure to be the culprit. I'll try to investigate.
Assignee: nobody → jfkthame
Keywords: regression
Priority: -- → P3
Whiteboard: [gfx-noted]
:gcp, could you try the build from and confirm whether that gives you a better result? (Don't worry about the reftest oranges there, I'm looking at them... but AFAICS on my local machine, at least, the glyph spacing looks fixed.)
Flags: needinfo?(gpascutto)
Yes, that looks way better.
Flags: needinfo?(gpascutto)
OK, this fixes the poor glyph spacing (and as a bonus, simplifies the code) by avoiding FT_Get_Advance, which doesn't seem to reliably give us the same rounding behavior as loading the glyph and reading from the slot. None of the test failures in the try run from comment 2 look significant; they just need small adjustments to fuzzy() annotations, etc. (Some are even unexpected-pass, where a previous discrepancy went away.) So I'll post a patch that makes the necessary adjustments, to be folded together with this for landing.
Attachment #8941781 - Flags: review?(lsalzman)
Deal with the adjustments to tests/expectations; to be folded into the preceding patch.
Attachment #8941782 - Flags: review?(lsalzman)
I've also noticed some strange font rendering on certain sites (e.g. ) in nightly on Debian. Running mozregression narrowed it down to which is bug 1427641 as suspected.
Attachment #8941781 - Flags: review?(lsalzman) → review+
Attachment #8941782 - Flags: review?(lsalzman) → review+
Pushed by
Don't rely on FT_Get_Advance for glyph widths, get the advance from the glyph slot instead for better consistency with cairo metrics & rendering; update test expectations for minor changes in rendering. r=lsalzman
Oops, this was accidentally omitted from the test-expectations update patch. I'll go ahead and push it as a followup, so we don't lose the updates if we do a fresh import of these tests; uploading here just for the record.
Pushed by
followup, refresh failures.list for updated test expectations. r=me (NPOTB)
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
After this landed I have huge rendering problems in Debian (stretch) with many sites. See Bug 1430216 for the details. Mozregression points to this bug.
This also resulted in failure to render Apple Color Emoji on Linux, see Bug 1430393 .
This is being deal with in Bug 1430216
(In reply to Eduardo Trápani from comment #14)
> This is being deal with in Bug 1430216

Yes I did see that but not sure it's totally the same because emoji fonts are scalable.
The current Nightly introduced the font rendering regression again. Not as bad as before, but still some letters are way to near to each other.
I saw it too, filed bug 1435234 and bisected it.
See Also: → 1440938
You need to log in before you can comment on or make changes to this bug.