The sad state of font rendering on Linux (2018)

Well, because it literally distorts the glyphs and thus doesn't actually look right, it would be like if some of the pixels on your screen were inexplicably the wrong color due to a color management issue. In some cases the distortion is really bad and doesn't even really improve legibility at all, so it's just a plain lose/lose. If you don't give a shit about typography in the least and don't care about the visual weight of text then fine, but not caring doesn't mean the behavior is correct by any means. (And keep in mind, you will often have more than one font size of text on screen at once, so this distortion will change the relative weight of fonts incorrectly, aside from also distorting the actual shape of glyphs.)

But OK, other than just being incorrect, does it matter? Many people don't have proper color management in their software and it's usually fine. Well, yes, sometimes it matters. For one thing, this issue really screwed up scaling in Win32 and even GTK+2, because if you tried to render dialogs with different font sizes it would completely change the UI and screw up some of the component sizing. OK, though, you can fix that by just not using a fixed layout. However, you still run into this problem if you want to render something that actually does have a specific layout. The most obvious example of how this can be a serious problem is something like Microsoft Word that is meant to give you a WYSIWYG view of a document on paper, but the paper is 300+ DPI and the poor screen is only 96 DPI.

Maybe most importantly, this is all pointless! We don't actually have to settle for these concessions for Latin script text on 96 DPI screens. Seriously, we really don't. I recommend this (old) article for a dive into the problems caused by non-scalable font rendering and how it could've probably been solved all along:

https://agg.sourceforge.net/antigrain.com/research/font_rast...

(Though to be fair, there are still problems with the approach of vertical-only hinting, as it does cause distortion too.)

(2019)

In the era of 4k screens, modern Linux distros have great font rendering and I won't take Windows as an example of "good rendering", unless font distortion because of strong hinting is a metric of quality. It is just atrocious to my eyes.

It's pretty easy to be honest: have a high-enough resolution screen, enable greyscale mode (instead of subpixel), turn off hinting. Usually only the latter has to be changed in the settings, as many Linux users still use 1080p screen that benefit from font hinting.

I keep hearing people talk about how Linux font rendering is supposedly so bad, but I simply haven't noticed any issues with it since switching from Windows on my home machine over 3 years ago.

> There is not even a hint of any consistency in the rendering either, thickness is all over the place even within a single glyph, with different strokes “sticking” together because of the lack of pixels:

Only the "H" looks even a little bit wrong to me.

> As you can see here, indeed, OS X had sub-pixel anti-aliasing in High Sierra, which provided less boldness and bluriness with somewhat better consistency in glyph thickness. However, colour fringing on High Sierra is rather apparent. Rendering is still rather blurry, closer to the FreeType auto-hinter than to what I would consider an optimal result.

The "H" looks just as wrong with and without this feature to me. Overall the new version without the feature is indeed a little bit "bolder" and "blurrier" - and given that it's white on dark grey, I'm pretty sure I prefer it that way.

> Thickness linearity between font sizes on the second image is fantastic. But compare the overall thickness at standard web font size (16px) to any other option and you will see that this comes at the cost of making everything bold by default:

Only the v35 version looks noticeably "less bold" to me here, although the autohinted version is perhaps a bit more blurry. But it's hard to imagine how "thickness linearity" could ever be accomplished without causing this sort of blurriness.

But maybe I'm just unbothered because I grew up with "luggable" Mac displays and bitmap fonts....

> With current state of Linux, it does not matter which engine you pick. They all are broken in the same way:

I searched the page for matching words (or at least letter combinations) and the actual rendered text isn't showing the same issues for me as in the screen capture.

> By the time I was updating this post in August 2019, Cairo received support for sub-pixel positioning in both xlib and image compositors. This means that GTK will soon have it too, as well as Pango and basically anything that relies on Cairo to render text. I am looking forward to the next Ubuntu LTS and might make a separate post about compiling this into the current Ubuntu LTS.

... Ah, I guess that must have happened, then.

----

On the other hand, GTK has caused me all kinds of problems. The default scrollbar theming is obnoxious, and if you fix it, it still doesn't seem to be consistently applied. Firefox does its own thing unless you look up an obscure about:config setting, and even then it still seems to mess up. GTK offers this really weird default style for window tabs(?) that required complete relearning, and that's with Cinnamon being supposedly designed for maximum Windows-alike-ness. Then there's the continued battle from GNOME to try to deny proper notifications and/or a system tray to everyone else. And don't even get me started on the file chooser.

Font rendering isn't the bottle neck on Linux, imo it's the terrible default font choices of distro and desktop environment makers.

> (it really is garbage if you're at all sensitive to fringing or use anything other than a standard LCD)

Human eyes have higher spatial brightness resolution than spatial color resolution. At the cost of software complexity and mild computation overhead, a screen like a Bayer matrix or technology-appropriate similar subpixel layouts together with software that properly anti-aliases content by clamping brightness and color resolution separately to appropriate values ensuring the screen will remain capable of showing the limit frequency and that the two limits are sufficiently close to not disturb the eyes/viewer, will result in better viewing than if you lazily forcibly clamp the brightness and color resolution to the same value as Apple did.

If you have a non-"default" screen subpixel layout then you need to remain able to drive each subpixel individually from the computer and to have the antialiasing algorithm be aware of the specific arrangement you have.

And no, until you can point me to a sub-2000$ (and at that price and that poor contrast, a minimum of 120 Hz) 35~55" screen with at least 2500:1 static contrast, a vaguely 16:9 aspect ratio (though I'll accept 4:3 with the same pixel count and density and accordingly scaled dimensions), and at least 10k individually addressed (and anti-aliased onto by the font rendering) horizontal pixels, I'll happily stay with my 11520 horizontal (sub-)pixels that I paid about 700$ for (43", 5000:1 static contrast, 60Hz).