Font smoothing method should be set system-wide, and not be under the control of a remote web page. What does the remote web page know about the kind of monitor the text is being viewed on? It could have a non-standard pixel layout, be rotated 90 degrees, be hiDPI, or be scaled.
> feel free to use it to fix custom font rendering on Windows<p>And then you get the exact opposite problem of macOS people trying to force macOS rendering onto other platforms because they prefer it. If you're going to advice people not to mess with these settings, don't make it apply to just your platform. Just don't touch these things unless you're going for some kind of retro feel or are foolish enough to try to do your own font rendering.<p>Apple's weird "font smoothing" probably has more to do with the way glyps are artificially altered for aesthetics, anyway. Stick to the platform defaults, it's what your customers are used to. Font rendering is done through lots of subjective choices and personal preferences because there's no technical "correct" font. If one platform does it different, let it be different, don't force down whatever your preference is because you use an iPhone/Windows tablet/Linux computer.<p>Funnily enough, Apple disagreed with this author and changed the way their subpixel algorithm worked years ago, so the author's preference clearly wasn't what the majority were expecting.
… not to be confused with the macOS concept that it has misnamed “font smoothing” which is absolutely nothing to do with font smoothing, but is instead glyph dilation—making fonts thicker than the designers intended them and than all other platforms (and anyone that turns it off in macOS’s settings) will get. I believe this to be a significant factor in many people using fonts at weight 300 at body sizes. See <a href="https://news.ycombinator.com/item?id=23553486" rel="nofollow">https://news.ycombinator.com/item?id=23553486</a> for some more details.
Stop trying to fix everything to be honest, so tired of encountering text inputs in React web apps that don't have system wide spellchecking because some engineer decided they needed to roll their own input controls.
> However, on Mac OS X, when this is reversed and you set light text on a dark background, you get a fairly ugly effect where the text becomes overly bold, spilling out of its lines.<p>Wait, that's not supposed to happen. Most likely they're setting subpixel values without taking display gamma into account. This should be fixed properly in the rendering pipeline.
I find it undesirable to let individual documents (or applications) to change/control fonts and colours in general, and usually restricting font changes by websites in FF, but sometimes noticing that some websites still manage to mess up the fonts by adjusting finer rendering options, as described here. Though it appears to be an even more general trend than that: reinventing and worsening built-in web browser functionality with JS is another common activity, as non-web software is prone to reinventing system functionality (or settings), and I usually imagine that the intent there is to "fix" things too (or at least to make them look prettier).<p>I wonder how much these "please stop" blog posts help: seems like they are supposed to raise awareness among developers, maybe to point it out to those who didn't think of it, but IME much of the awkwardness, especially in the UI, comes from non-tech-savvy client/user/management requirements: things must look good enough in a presentation, on their machines, and/or on common machines and systems at the time (though an argument can be made that it's the priority in many cases).
<i>mobile devices don’t use subpixel rendering due to having to suport both vertical and horizontal screen orientations</i><p>Sure about that? I would've thought the wildly varying subpixel layouts for the various display technologies and even generations of a particular technology would have a bigger impact. IPS subpixel layout looks nothing like an early PenTile layout which is different from a modern AMOLED layout.
This article should be suffixed with “(2012)”.<p>In the past ten years, Macs (which this writer is mostly concerned with) have all adopted ultra high density “retina” displays, which… well I’m not going to say they render the arguments moot, but the changes are so drastic that they force every statement to be reevaluated.<p>Also I could be mistaken but I believe as of about four years ago subpixel was dropped from Macs altogether.
What I (on Windows) found interesting, was that I thought the subpixel rendering screenshot looked clearly worse and more blurry… on my FHD Monitor. On a hunch, I dragged it to my WQHD Monitor and indeed, that reversed which of the 2 examples I found to be more blurry.
This is an old article and I think <i>designers</i> kinda stopped doing this because its effect is not as pronounced on high-res displays.<p>Either way, 100% agree. Stop trying to change a OS’s text rendering, if you still are.
I always use the links terminal browser test. If the site is usable in my terminal with the `links <a href="https://usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/" rel="nofollow">https://usabilitypost.com/2012/11/05/stop-fixing-font-smooth...</a>` command then it is well done. Chances are, if you are using any type of special font rendering to fix a UI issue you are also doing other things on that page that will cause it to not display properly in links. Also, shout out to the author for having their article actually render well in links!
Arguably much of the “infrastructure” and visual language for GUIs have evolved in the light background/dark text scenario, and “dark mode” has been pretty much improvised in the past couple of years.<p>I work mostly in the daylight and thus mostly in light color schemes for coding (doubly so when I’m forced to use glossy screens) but I get the appeal of not having a full white spotlight in your face when coding something in bed at 3AM. But: I’d rather most of my screen be dark (eg with terminals) but still have my editor viewport to be light-background, even if it means shrinking it.
They have images comparing subpixel and anti-aliased fonts, but if I understand correctly the subpixel interpolation takes place at a different level of the stack and the required metadata is lost when it's been rasterized... the subpixel example looks way blurrier than the anti-aliased example.
Exactly controlled font rendering and color accuracy over the web are impossible to get exactly right because what is correct for one OS/GPU/screen combination will not be correct if you change OS or screen (and sometimes GPU).
Still relevant, although in different applications. GTK removed subpixel font rendering in GTK+4 (or more precisely, changes were made in Pango), that resulted in blurry fonts. Official explanation is that subpixel rendering is incompatible with transformations. Some work is being done on partial fixes, but results are not as good as current font rendering on GTK+3 applications.
<a href="https://gitlab.gnome.org/GNOME/gtk/-/issues/3787" rel="nofollow">https://gitlab.gnome.org/GNOME/gtk/-/issues/3787</a>
I though sub pixel rendering (or anti-aliasing) was not needed at all on modern HiDPI displays? Why do you need to anti-alias anything if you are already rendering glyphs with sub(logical)pixel precision anyway?
> But upon closer inspection, antialiased text is always blurrier than subpixel rendered text. This is not a matter of opinion, it’s just how the rendering works.<p>That is not generally true. It depends on font hinting and grid-fitting. With good grid-fitting, font rendering with disabled subpixel support is more sharp, as vertical lines are exactly aligned with pixel boundaries. That is why i disable it on my desktop.