Conversation

Any Chromium contributors around to answer that one? I've seen it a bunch on some Linux distros and have no idea what's causing it.

Quote Tweet

rain

@sunshowers6

Jun 15

Why is Chrome font rendering on Linux so much worse than Firefox? Firefox is on the left -- everything's beautifully laid out, close to perfect to my eyes. Chrome on the other hand, the t's have a weird space after them, the i's meld into the o's--it looks so bad in comparison

Show this thread

Screenshot of the cargo-nextest homepage on Firefox and Chrome running on Linux -- Firefox (left) has significantly better font rendering than Chrome (right)

read image description

ALT

Replying to

and

Likely broken font configuration with applications using different versions of the font rendering dependencies. If that's the official Chrome package, these dependencies are bundled and will be different than the OS versions. Most distributions link the system ones for Chromium.

Replying to

and

gist.github.com/thestinger/767 in ~/.config/fontconfig/fonts.conf is a reasonable default configuration. Important to note that hintfull is no longer properly supported in the current font rendering stack and auto-hinting has always been prone to very weird issues depending on fonts.

gist.github.com

fonts.conf

GitHub Gist: instantly share code, notes, and snippets.

Replying to

and

Interesting... any idea why Firefox is totally fine tho?

Replying to

and

No, but it's quite possible one of them is respecting settings from something like GTK or GNOME configuration and the other is ignoring them. Chromium and Firefox both have quirky desktop Linux integration because there's no standard way to do a lot of the things they want.

Replying to

From my digging into this, Firefox is better at respecting the actual font configuration, but this causes other problems in some cases where distro maintainers ship broken font configurations from ChromeOS:

bugzilla.mozilla.org

1481545 - Poor kerning of fully hinted fonts on Linux (affects Roboto -> Gmail)

REOPENED (nobody) in Core - Layout: Text and Fonts. Last updated 2021-03-13.

Replying to

Here's another example of distro's just shipping wildly broken font configuration files:

bugzilla.mozilla.org

1763175 - Firefox font regression in Arch Linux (KDE plasma 5.24.4)

RESOLVED (nobody) in Core - Widget: Gtk. Last updated 2022-04-09.

Replying to

That specific example is definitely a user configuration change since github.com/archlinux/svnt ships an unmodified upstream configuration. In general, Arch doesn't apply patches or configuration changes and installing stuff doesn't automatically start running services, etc.

Replying to

Main reason I use not just on my workstations but on all the GrapheneOS servers is because I don't have to spend time debugging downstream changes. Does mean when upstream doesn't have good defaults, it's all on you to figure out how to set things up properly. I prefer that.

Replying to

One thing that's worth doing for everyone is running `fc-match sans`, `fc-match sans-serif` and `fc-match monospace` and making sure those are 3 high quality fonts you personally like. Also nice to get rid of as much as possible so you fall back to those as often as possible.

4:19 PM · Jun 16, 2022Twitter Web App

Replying to

Removing en.wikipedia.org/wiki/Core_font if your distribution provides it is crucial since they're ancient, terrible variants of the fonts. Even modern variants don't render properly on Linux since they gave up on chasing full ClearType support and Microsoft built newer fonts around it.

en.wikipedia.org

Core fonts for the Web - Wikipedia

Replying to

I'm perfectly happy installing Source Sans Pro / Source Serif Pro / Source Code Pro and using gist.github.com/thestinger/d9d. Linux font rendering peaked when the perfectionist working on Infinality was around with their complex patches and configurations but it all bitrotted away.

gist.github.com

~/.config/fontconfig/fonts.conf

~/.config/fontconfig/fonts.conf. GitHub Gist: instantly share code, notes, and snippets.