Closed Bug 1435234 Opened 7 years ago Closed 7 years ago

Font rendering (kerning) regression on Ubuntu 16.04

Categories

(Core :: Graphics: Text, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox60 --- fixed

People

(Reporter: gcp, Assigned: jfkthame)

References

Details

(Keywords: nightly-community, Whiteboard: gfx-noted)

Attachments

(12 files)

Bug 1428826 has regressed again, as noticed in the bug by other users. Visible in URLbars links such as: mozilla.org or irccloud. ^^ ^^ Where the spacing is too narrow to be readable. I bisected this to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b19b1b50594e7e9d075e9dcb27bc88fe25850c95&tochange=1e5e317d90ecf586136e626bb3f2552f198ef0bc
Blocks: 1430446
Attached image badkerning.png
In the linked (original) bug there's a very nice example of kerning that can't be right, but it's not stated on which webpage. Here's one from the URLbar. As you can see, the near-nonexistent spacing between I and R in irccloud is very inconsistent with the spacing of the other letters.
Attached image screenshot2.png
I'm encountering the kerning bug in the attached screenshot ("ShowAll Downloads") with the following combination: * Firefox Developer Edition 59.0a5 (64-bit, up to date as of this posting) * Lubuntu 14.04.05 LTS * A desktop that has been apt-getted into a mostly KDE configuration * "Ubuntu" as the system font The "Show All" sequence used in the UI does contain a space according to the developer tools, it doesn't produce the kerning bug anywhere else on my system that uses the "Ubuntu" font, and changing the font within the developer tools causes the kerning bug to go away. Should I file a separate bug for this?
I agree those screenshots look pretty bad! What's a bit puzzling, though, is that I'm not seeing similar poor spacing on my Ubuntu system; for comparison, here's how the address bar looks for me. Clearly there are other factors leading to differences in behavior here.
https://pastebin.mozilla.org/9077201 This is the full config: anti-aliasing, slight hinting, rgb subpixel, lcdfilter default.
Hi there, I'm experiencing similar issues. I'm using Arch Linux with i3-gaps, kernel 4.15.2-2-ARCH. It doesn't appear to be anything to do with graphics drivers as I've tried with both NVIDIA and Intel GPUs being used. I've started with a clean profile and also have the same issues. The issue has been present for me in both Firefox Nightly (60) and Firefox Developer Edition (59.0b8). I've tried a few different fontconfig configurations, but none seem to make a difference to the kerning. I thought it could be hinting at first, but it doesn't appear to be (I have it disabled normally). I'm going to attach a few Chrome vs. Firefox comparisons to highlight the issues.
Attached image chrome-v-firefox-a
Attached image chrome-v-firefox-b
Just a little bit extra to add, with the BitBucket example above, I did notice that they have used some negative letter spacing, but only a very tiny amount. If you increase or decrease that number (but still keep it relatively small) then you can see other letters group up - the ones that group up will change, as if Firefox is attempting to make the overall width of a piece of text "work" at that letter spacing on average, but also trying to not rely on anti-aliasing maybe? I'm not really sure how to describe that any other way.
Me too. Top: gedit. Bottom: Firefox. Same text, same font (Liberation Sans at 12pt (16px)), slight hinting, rgb filtering, 96 pixels per inch. Lorem ipsum dolor sit amet, consectetur adipiscing elit. ^^ ^^ ^^ ^^ ^^ ^^ Any text involving the cyrillic letter щ becomes exceptionally ugly. Mozregression says: INFO: Last good revision: b19b1b50594e7e9d075e9dcb27bc88fe25850c95 INFO: First bad revision: 1e5e317d90ecf586136e626bb3f2552f198ef0bc
Has Regression Range: --- → yes
Attached image collage.png
I have performed more bisections, this time looking at the print preview, again with Liberation Sans at 12pt. I arrive at the following conclusion: * 48cddb40b16b99fac6342b6503b0b6e67be4dbc2 was the last good version (top section of the attachment). * Then bug 1427641 landed and broke kerning visibly, both for screen and print (bottom section; observe too dense Ve, Ae, ve, too sparse kerning around s). Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=48cddb40b16b99fac6342b6503b0b6e67be4dbc2&tochange=a85c5795cc6f0db71e13288e849ef47b2f225270 * Then bug 1428826 landed and fixed kerning for screen. On print, kerning became better but still suboptimal (middle section; observe that almost every pair is more sparse, except for those starting with ‘t’ or ‘f’, which are more dense). Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ed7d701658926c75bff77885d3258b2860d6dc3b&tochange=56f88b76d0fd6b0b207de727891610132e9a67a4 * Later, bug 1430446 landed and broke kerning again (bottom section). Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b19b1b50594e7e9d075e9dcb27bc88fe25850c95&tochange=1e5e317d90ecf586136e626bb3f2552f198ef0bc
Rather frustratingly, I still can't seem to reproduce this on my Ubuntu (16.04) system. I've tried to replicate the settings described in comment 9, but I still get decent spacing with Liberation Sans, as seen in this screenshot. (The image from comment 9 is also included for comparison.) This makes it tricky to try and diagnose what's going wrong here, or to test possible patches. :( Lee, can you reproduce this, by any chance? Any ideas what might be happening?
Flags: needinfo?(lsalzman)
(In reply to Jonathan Kew (:jfkthame) from comment #11) > Created attachment 8953145 [details] > Screenshot comparing my rendering of Liberation Sans with example from > comment 9 > > Rather frustratingly, I still can't seem to reproduce this on my Ubuntu > (16.04) system. I've tried to replicate the settings described in comment 9, > but I still get decent spacing with Liberation Sans, as seen in this > screenshot. (The image from comment 9 is also included for comparison.) > > This makes it tricky to try and diagnose what's going wrong here, or to test > possible patches. :( > > Lee, can you reproduce this, by any chance? Any ideas what might be > happening? If I force slight hinting in fontconfig, and then I open up the "history, books, and more" icon, in the word "Downloads", "wn" is squished together. That's what I can repro so far. No idea what is going on offhand.
Flags: needinfo?(lsalzman)
Whiteboard: gfx-noted
(In reply to Lee Salzman [:lsalzman] from comment #12) > If I force slight hinting in fontconfig, and then I open up the "history, > books, and more" icon, in the word "Downloads", "wn" is squished together. > That's what I can repro so far. No idea what is going on offhand. I can confirm, hintnone and hintslight will have bad font kerning. With hintmedium or hintfull everything looks like it should, but this style looks ugly to me.
:gcp, and others who are seeing this issue, could you please try the tryserver build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=84e01f54ce5ad7e23cd281e74c38f6a446771e38 and confirm whether that improves things on your configuration? Thanks!
Flags: needinfo?(gpascutto)
I'm sorry, but how am I supposed to download a build from that site? I'm not a developer and have absolutely no idea how to use that site.
The build jobs (as opposed to the multitude of test jobs, which you can ignore) are shown as "B", and if you select one of those (e.g. the Linux x64 Opt build), it will show a list of associated "build artifacts" that are available for download. The actual build you want, then, is the target.tar.bz2 file, which you can unarchive into a local directory; then run the firefox executable found there. So for Linux x64, the actual download link would be https://queue.taskcluster.net/v1/task/HmIFDAMwSoiV8kdRvoPKnw/runs/0/artifacts/public/build/target.tar.bz2 Hope that helps. (Also, note that I think you need to make sure you exit your existing copy of the browser before running an alternative build, otherwise trying to launch it may instead open a new window in your already-running copy.)
Hey there, just taken that build you've linked for a spin. I can see a big improvement to what the Amazon autocomplete looks like that I attached before. I'll attach a new screenshot of that as it is now in that new build you posted. Unfortunately, BitBucket still has a big issue with kerning. The difference I can see is with how Firefox is handling the CSS letter-spacing property. It still seems to just apply the letter spacing that should be averaged out across the whole word to a single pair of letters. Like the word's-worth of letter-spacing is focused in one area, and the rest of the word just looks like it would without any letter spacing. I'll attach another screenshot of that too.
The linked build does improve the kerning for me as well, but it's still not perfect. Letters are not overlapping any more, but some letters still are too near together. I will attach a screenshot as well of this posting: https://www.hardwareluxx.de/community/f219/asus-prime-x370-pro-am4-1156996-283.html#post26181448
Attached image mG76H0Y.png
For comparison, this is that BitBucket menu on Chrome, by the way. Just to show it's not a BitBucket issue.
Interesting - thanks for the screenshots. I wonder if the remaining issues here are the same as reported in bug 1441843, which apparently dates back as far as Firefox 58 (and so may be a separate issue from the spacing problems introduced by bug 1427641 and its followups, which didn't land until the mozilla-59 cycle). Could you compare results for the bitbucket example with Firefox 58? In principle, I think the build from comment 14 ought to revert to the same glyph spacing as we had then, unless things have changed elsewhere in the graphics code in a way that affects this.
On my machine, with this build, screen rendering is back to normal; print preview still slightly weird.
Am I correct that the fixed rolled into Nightly? Both Nightly and the linked build seem to be much better?
Flags: needinfo?(gpascutto) → needinfo?(jfkthame)
I'm just left with the issue of odd letter spacing on some sites now. Nightly / the above build was indeed a big improvement for me. I'm left with the same issue as in bug 1441843
OK, I think we can close this bug, as the regression was fixed (in bug 1440938). The remaining issue (bug 1441843) seems to be a pre-existing problem (not a recent regression) and is more specifically related to the use of letter-spacing.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → FIXED
Assignee: nobody → jfkthame
Appears to have resurfaced in 63.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: