The sad state of font rendering on Linux (2018)
pandasauce.org
pandasauce.org
https://agg.sourceforge.net/antigrain.com/research/font_rast...
Though to be fair to this article, Microsoft did improve things with DirectWrite, and yes the situation on Linux is quite bad unfortunately.
Also bonus, a pretty great article here talking about gamma correctness in font rendering, an issue that is often somewhat overlooked even when it is acknowledged.
https://hikogui.org/2022/10/24/the-trouble-with-anti-aliasin...
Just some additional reading materials if you're interested in this sort of thing.
I haven't owned a smartphone with a screen resolution that low, in over 10 years.
I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions.
Of course 16:19 pushed down display costs leading to the demise of 1920x1200 which is unforgivable ;-)
Those 120 pixels were sorely missed.
You know... as you age, you really can't read all those tiny characters anyway.
If something needed to be rendered in some particular way, it should have been a PDF. For everything else there’s vim.
> I haven't owned a smartphone with a screen resolution that low
Smartphone in italics, because smartphones are known for their low pixel densities, right? What?
Did you own a smartphone at all in the past 10 years? Just double checking.
> I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions.
And how did you reach that conclusion? Did you somehow miss display companies selling and pushing 1440p and 4K monitors left and right for more than a handful of years at this point, and yet the Steam Hardware Survey still bringing out 1080p monitors as the king month to month?
Sometimes I really do wonder if I live in a different world to others.
No, it was limited by the bandwidth of the beam driving system, which the manufactures, obviously, tried to maximize. This limit is what set the shadow mask and RGB sub pixels/strip widths. The electron beam couldn't make different color, different colored phosphor patches were used.
But, since bandwidth is mostly resolution * refresh, you could trade between the two: more refresh, less resolution. More resolution, less refresh. Early on, you had to download a "driver" for the monitor, which had a list of the supported resolutions and refresh rates. There was eventually a protocol made to query the supported resolutions, straight from the monitor. But, you could also just make your own list (still can) and do funky resolutions and refresh rates, as long as the drive circuit could accommodate.
This monitor could do something like 75Hz at 800x600, and I think < 60 at 1080p.
> This monitor could do something like 75Hz at 800x600, and I think < 60 at 1080p.
Assuming both modes were meant with 24-bit color ("true color"), that'd mean 17.36 Hz tops then for the FHD mode, ignoring video timing requirements. I don't think you were using that monitor at 17 Hz.
Even if you fell back to 16 bit color, that's still at most 26 Hz, which is miserable enough on a modern sample-and-hold style display, let alone on a strobed one from back in the day. And that is to say nothing of the mouse input feel.
Because that thing could only do the BIOS text modes, and standard VGA at 640x480 at 60 or 70Hz. Anything else just showed OUT OF SYNC on the OSD, and then switched off.
Except when you fed it 800x600@160Hz, 1024x768@144Hz, 1280@120Hz and 1600x1200@70 to 80Hz, or anything weird in between.
I could easily do that under XFree86 or early X.ORG. A gamer under DOS/Windows rather not, not even with Scitech Display Doctor, because most games at that time used the hardware directly, with only a few standard options to chose from.
OUT-OF-SYNC zing
Was nice for viewing 2 DIN-A4 side by side in original size :-)
Fortunately a Matrox I had could drive that, as could a later Voodoo3 which also had excellent RAMDACs and X support.
Was a bit surprised by that double A4 thing btw, but I did the math and it checks out - paper is just surprisingly small compared to desktop displays. Both size and resolution wise (1612×1209 would have put you right up to 96 ppi, with regular 1600×1200 being pretty close too). It's kind of ironic even, the typical 1080p 24" 60 Hz LCD spec that's been with us for decades since just barely fits an A4 height wise, and has a slightly lower ppi. Does have some extra space for sidebars at least, I guess.
[0] Update: ah right, it wasn't a pixel clock limit being ran to the limit there, but the horizontal frequency.
Did care about 1600x1200 at then 75Hz mostly. All that other stuff was just for demonstration purposes for other people coming by, or watching videos fullscreen in PAL.
It seemed to be really made for that resolution at a reasonable frequency, with the BIOS & VGA thing just implemented to be able to see start up, changing settings, and all the rest just a 'side-effect'.
No, literally, on the roadside, out for trash. Disposing of CRT has always been expensive since they can't fit in the trash and taking them to the dump has a fee for the all the lead. At the transition to LCD, they were all over the place, along with projection TVs. There was also a lot of churn when "slimmer" versions came out, that mostly halved the depth required. Again, it was literally 50lbs, and about 2ft in depth. It took up my whole desk. It was worthless to most anyone.
> Smartphone in italics, because smartphones are known for their low pixel densities, right? What?
Over 10 years ago I had an iPhone 6 plus, with 1080p resolution. All my phones after have been higher. Their pixel densities (DPI) are actually pretty great, but since they're small, their pixel counts are on the lower side. There's nothing different about smartphone displays. The display manufacturers use the same process for all of them, with the same densities.
Stereo audio is still fine even though 5.1 exists
300 dpi printers are still useable even though 2400 dpi printers exist
double-glass windows are still fine even though triple-glass windows exist
2-wheel drive cars are still fine even though 4-wheel drive cars exist
Just because something new appears on the market that new thing does not need to take over from all predecessors when those predecessors are good enough for the intended purpose, especially not when the new thing comes with its costs - power use and higher demands on GPUs in case of display with higher resolutions than really needed.
Fire is fine, even though ovens exist.
We're animals, that are perfectly fine living naked in the wild (some still do today). It's all complete excess. Feel free to abandon the progression of tech, but, I challenge you to use a modern panel for a couple months, then try to go back to 1080p. It's like the console players who claimed 30fps was serviceable, fine. Sure, but nobody wants to go back to 30fps after they've used 60hz, or 144hz, for a non-negligible amount of time.
I also use a 1080p from time to time, it's servicable, but it's not comfortable, and it provides a far far inferior experience.
That's something that OSX doesn't even have now.
Thats why there can be quite big quality jump when you compare it to fonts from big design teams from Apple or Microsoft. Not only the font might be a bit worse, the rendering/hinting is often way worse.
Mac OS dropped the subpixel garbage (it really is garbage if you're at all sensitive to fringing or use anything other than a standard LCD) in favor of high pixel density screens. Sharp, readable text and zero color fringing. This is the way.
I don't even have to edit anything on Windows now, and when I did a few years ago it was only on a clean install going through I think what was called cleartype config, you had a panel of 6 images/samples to choose from and after going through it all everything looked pretty damn perfect.
I wish I could download an OS update that gave me a high pixel screen! But, uhhh, that’s not how it works.
Restaurants spend tens or hundreds of thousands of dollars on equipment so that their staff can work more efficiently. Why doesn't IT people take inspiration from them and get a bit better equipment. It's not a luxury item.
Philips have a very good one at 27 inches.
bwahaahaha, and you are talking about eye strain. Number one thing I do if I want to improve QoL for my eyes is getting a larger monitor so I could see more without looking like the last guy from the famous human evolution culminating in sitting in front of computer pic.
Not high enough pixel density causes which one of these again?
> Why doesn't IT people take inspiration from them and get a bit better equipment.
Are we talking about the same field where people are having a competition about who can build the most overpriced and obnoxious sounding keyboards imaginable?
Some IT people and computing enthusiasts are total consumers, I don't disagree. But it's also the only profession / serious hobby where it's common for people who are doing it all day insist on having the cheapest equipment, or half broken hardware. Not in the case with the commenter above, who I misunderstood in some way.
Linux had a very bad appearance in the past with a default configuration, and it still does not look good in most distributions, but that is not due to bad rendering algorithms, but it is due to the fact that the default free typefaces are usually not very good.
For several decades, the first thing that I have always done after installing Linux was to delete all default typefaces and replace them with some high-quality typefaces, most of which I have bought, with a couple taken from a Mac OS and a Windows that I had bought in the past (which I have stopped using many years ago, except for the few typefaces that I have kept from them).
Because of this policy, any text on my Linux computers has always looked much better than on any of the Windows or Mac OS computers that I have used at work.
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).
There was definitely a time when, to get good results, you had to do a lot more tweaking, setting things in fontconfig, using patched Freetype, but I don't really experience that anymore now for quite some time. I do still bring around a fonts.conf to my machines basically out of habit... the only relevant thing it does now probably is disable embedded bitmaps.
It's always a little bit of whiplash seeing how different this very site looks when I occasionally am on a Windows machine, with Verdana rendering quite differently there, and to my mind, worse.
You could also set the RGBA vs whatever pixel layout in the same Gnome settings dialog. Easy-peasy adjustment for a VA panel.
After, it was available only in gconf/dconf or a tool like gnome-tweaks or similar.
MacOS is definitely terrible today, but I prefer Linux over Windows still.
There's also an entire world of users still on 720p and 1080p displays. They deserve better font rendering even if it doesn't affect us personally.
Put yourself in the shoes of the average computer purchaser: Would you rather buy a high PPI monitor, or two standard PPI monitors? To me this is a no-brainer.
FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0"
Fits with me - long time mac user i like Mac rendering, linux feels very similar and i like it. Windows feels like somebody is burning the fonts into lcd. It is probably more legible in tiny sizes on low pixel screens but it is too strong and not very elegant everywhere else.
This is because these font files originate from a Microsoft initiative called "Core Fonts for the web" that ran between 1996 and 2002. Before web fonts became a thing, Microsoft wanted to make a set of broadly available fonts that web designers could assume everyone had on their computers. Because Microsoft cancelled the initiative, the redistributable versions of those fonts are stuck in time. They were last updated around 2000, and any updated versions with further improvements or added characters aren't freely redistributable.
v40 with slight hinting and greyscale or subpixel works, but I don't tend to use the fonts that are meant to be used with slight hinting and later fonts can't handle anti-aliasing off at all.
You can easily do this on a per-app basis with flatpaks.. you can set an environment variable with flatseal, and you can drop a fontconfig folder with a custom fonts.conf in the flatpak's var directory.
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.)
Like fine, let's put aside somewhat intentional things like hinting and grid-fitting with accumulating error for a minute. Some FreeType configurations dramatically fuck up the visual weight of fonts, making the regular style in a type face look fairly bold. The damn font looks wrong. It's not "wrong" as in I disagree with what the designers intended for the type face, it's wrong as in it looks nothing like the designers intended and it looks nothing like the parameters you put in to render the font. There is basically no perspective where this output is desired, it's just a bad rendering.
There's definitely a bit of subjectivity in exactly where to draw the line, but there is definitely still a line you can cross that just goes into blatantly wrong territory. The relative visual weight of a glyph is not supposed to be influenced by its size on screen.
The sad state of font rendering on Linux - https://news.ycombinator.com/item?id=41812358 - Oct 2024 (18 comments)
The sad state of font rendering on Linux - https://news.ycombinator.com/item?id=19312404 - March 2019 (167 comments)
Until it got more or less resolved by upstream with modernized components, and made redundant.
You don't have to splurge to get a 2160p monitor that a Mac will love.
Roll back to a version of OSX that predates Retina, and _all_ of your monitors get the expected Mac-like font rendering, Retina or not. Go to 10.7 or newer, and all monitors are ran using the Retina tuning for font rendering, which makes it very smeary and blurry on normal monitors, but looks great on anything that triggers Retina rendering.
So, what I've been advising to the fewer and fewer Mac owners I know that want multi-monitor: only buy 4k monitors, OSX thinks they're HiDPI and won't fuck over your font rendering. At least, they won't today.
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.
If I need to do typographic work, I can zoom in enough for this to not matter, or just print a proof on a laser printer; no screen is going to have 1200dpi any time soon anyway.
Windows 10 takes the second place (I have no Win 11 machines around to compare), and macOS is still only usable on retina screens.
> 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.