1847515 - Font rendering (Linux): Bad kerning since Firefox 116

Status: UNCONFIRMED

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

Description

[Ralf Jung]

Attachment: Screenshot from 2023-08-07 11-18-54.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Font rendering in Firefox became a lot worse recently. This seems to coincide with the update to FF116, but it is also possible that a system update ("apt upgrade") I did around the same time is partially responsible. This is on Debian testing, using Gnome as my DE.

One page where this is particularly visible is Zulip, in my case https://rust-lang.zulipchat.com/. I have attached a screenshot of how this renders in Firefox for me, I hope you agree that terrible: in "about hardware", the "t" is as close to the "h" as it is to the "u", making it very hard to see where one word ends and the next begins. Similarly, in "is in ma" you can see that there is barely any space between "is" and "in", certainly a lot mess than between "in" and "ma". The gap between the two letters of "ma" is basically as big as the space between "is" and "in"!

Actual results:

See attached screenshot

Expected results:

Text should look better (and it used to look better until around a week ago). The same pages look a lot better in Chromium, so I assume this is a Firefox issue.

Comment 1

[Ralf Jung]

Attachment: font samples.png

Here's a screenshot of this message side-by-side in Firefox and Chromium. You can clearly see how the Firefox rendering is a lot worse, e.g. look at "consistency" and how there is a bug gap before "cy", or look at "If" with the gap between the two letters. In "but I", the "t" is as close to the "I as it is to the "u".

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Ugh, yeah, that rendering looks terrible :)

Any chance you could run mozregression on your system to see if it was triggered by Firefox? I can't repro on nightly on the rust Zulip.

Something like:

$ pip3 install --user mozregression
$ mozregression --good 115 --bad 116 -a https://rust-lang.zulipchat.com

Or so. But yeah that's clearly broken.

If it still repros on 115, then right-clicking the message, going to the font panel, and listing the fonts that are getting used would be useful. Would also be useful to know if this repros with a clean profile.

Thanks!

Comment 4

[Ralf Jung]

It looks terrible even on a clean profile with Firefox 115.

So maybe some other component of the system regressed? How would one even go about debugging this?

The Chromium where it looks good is running inside Flatpak so it is probably isolated from whatever change on my system is causing this...

Comment 5

[Emilio Cobos Álvarez [:emilio]]

My bet would be on a freetype or fontconfig update, somehow. What versions of those libraries are you using?

If you inspect the page with broken kerning, and click on the "Fonts" panel, that should give you the actual fonts Firefox is using. Which ones are they? With those names, you can probably:

• Look up if they're the expected font. Looking at Zulip, they seem to be using font-family: "Source Sans 3 VF",sans-serif, where Source Sans 3 VF is a web font. So I'm not sure how this can really be going wrong (maybe if font variations are disabled?):

@font-face{
    font-family: 'Source Sans 3 VF';
    font-weight: 200 900;
    font-style: normal;
    font-stretch: normal;
    src: url('WOFF2/VAR/SourceSans3VF-Roman.ttf.woff2') format('woff2'),
         url('WOFF/VAR/SourceSans3VF-Roman.ttf.woff') format('woff'),
         url('VAR/SourceSans3VF-Roman.ttf') format('truetype');
}

@font-face{
    font-family: 'Source Sans 3 VF';
    font-weight: 200 900;
    font-style: italic;
    font-stretch: normal;
    src: url('WOFF2/VAR/SourceSans3VF-Italic.ttf.woff2') format('woff2'),
         url('WOFF/VAR/SourceSans3VF-Italic.ttf.woff') format('woff'),
         url('VAR/SourceSans3VF-Italic.ttf') format('truetype');
}

• See if changing the font in the inspector fixes the kerning?
• Is there any local fontconfig override for Source Sans that could be applying here? (grep for Source Sans or so in /etc/fonts or ~/.config/fontconfig)? If so, maybe we're applying it to web fonts incorrectly?
• What distro / desktop environment are you using? Maybe I can repro locally somehow...
• What is the value of layout.css.font-variations.enabled? Does toggling it and restarting help?

Comment 6

[Jonathan Kew [:jfkthame]]

Agreed, that looks terrible. But doesn't reproduce for me either (on Ubuntu).

If you go to about:config and set the gfx.text.subpixel-position.force-enabled pref to true, and then restart the browser, does that make any difference?

Comment 7

[Ralf Jung]

Look up if they're the expected font. Looking at Zulip, they seem to be using font-family: "Source Sans 3 VF",sans-serif, where Source Sans 3 VF is a web font. So I'm not sure how this can really be going wrong (maybe if font variations are disabled?):

Yes, I'm seeing the same font, "Source Sans 3 VF". If I change it to just sans-serif it picks my local sans-serif default and looks much better.^^

Is there any local fontconfig override for Source Sans that could be applying here? (grep for Source Sans or so in /etc/fonts or ~/.config/fontconfig)? If so, maybe we're applying it to web fonts incorrectly?

grep doesn't find anything.

What distro / desktop environment are you using? Maybe I can repro locally somehow...

Debian testing, Gnome.

What is the value of layout.css.font-variations.enabled? Does toggling it and restarting help?

In my new clean test profile it was true. Setting it to false makes everything look very different, now the text is so light it is barely readable on the white background. The kerning is a bit different but still bad.

If you go to about:config and set the gfx.text.subpixel-position.force-enabled pref to true, and then restart the browser, does that make any difference?

That's better but still not great. I will attach a screenshot.

Comment 8

[Ralf Jung]

Attachment: Screenshot from 2023-08-15 17-37-43.png

Screenshot with gfx.text.subpixel-position.force-enabled = true

Comment 9

[Ralf Jung]

I tried installing the Firefox flatpak and got the same result. But, I have xdg-config/fontconfig shared with the flatpak. When I remove that, things look good in Firefox. If I rename that folder, also the regularly installed clean Firefox starts looking good.

So... somehow something about my local fontconfig, which I didn't change in forever, recently started disturbing Firefox but not Chrome? (Or something "helpfully" changed my fontconfig in a way that disturbs Firefox but not Chrome.)

So I put the config back file by file, and it looks like something in my fonts.conf made it unhappy. That file hasn't changed since March 2021.

Specifically this seems to have been the bad part:

<match target="font">
<edit mode="assign" name="hintstyle">
<const>hintmedium</const>
</edit>
</match>

There's some other stuff in that file about which I don't know if I can remove it or not.
I don't know how this got there. I surely didn't edit this file by hand, but probably some settings UI I used wrote that.

Comment 10

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

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[nunya_b]

this occurs on macOS as well.