Please Stop “Fixing” Font Smoothing (2012)

https://usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/

by damir • 5 years ago

114 85 5 years ago

rudian3• 5 years ago

This is an old article and I think designers kinda stopped doing this because its effect is not as pronounced on high-res displays.

Either way, 100% agree. Stop trying to change a OS’s text rendering, if you still are.

chronogram• 5 years ago

[2012]

This isn’t relevant anymore. This flag only affects older versions of macOS.

rudian3• 5 years ago

That's not true, I can replicate it in Chrome 96, macOS 11. It doesn't seem to work in Firefox though.

robin_reala• 5 years ago

In Firefox, people historically used -moz-osx-font-smoothing: grayscale;

kalleboo• 5 years ago

And specifically macOS hasn't used subpixel antialiasing since 10.14 Mojave was released in 2018

mnw21cam2• 5 years ago

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.

BlueTemplar5• 5 years ago

Yeah, the

mobile devices don’t use subpixel rendering due to having to suport both vertical and horizontal screen orientations

makes no sense... (well, except that doing it properly would be harder to implement)

maskros3• 5 years ago

"Subpixel" rendering (a.k.a. cleartype) that abuses color fringing to provide higher luminance resolution only works when you have pixels made of three RGB columns. Mobile screens usually use a pentile pattern, so this trick is not just more difficult, it's actually impossible.

zozbot234• 5 years ago

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.

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.

elondaits• 5 years ago

Maybe… but it’s been like that for years and years now (a decade, even?) so you can’t blame web designers for disabling subpixel smoothing in that scenario.

nevir• 5 years ago

This has been a known bug for well over a decade: https://www.lighterra.com/articles/macosxtextaabug/

I wouldn't hold your breath on a rendering fix

Apple 'fixed' it in 10.14 by disabling subpixel anti-aliasing all together (what this post argues against)

rob74• 5 years ago

Well, as long as you use Hi-DPI (or "Retina", as Apple likes to call them) displays over your entire product line, subpixel rendering doesn't have as big of an impact anymore. I also suspect that's what's going on with the designers who are wont to disable subpixel rendering for their sites: they also mostly have Macs with Hi-DPI screens, so they don't see the benefit of subpixel rendering.

BearOso• 5 years ago

Yep, this whole article misses the point that the gamma wasn't being corrected for, so the opacity wasn't linear relative to the requested percentage.

Sadly, the only thing that ever did this correctly was Firefox, and it no longer does it. The proper method needs alpha values maintained for each subpixel in an image, not just each pixel, and it needs a specialized blit routine to composite with the background. This was agreed by most to be too complex, and, as other comments point out, DPI is increasing, so the easiest thing is to just disable subpixel rendering.

chrismorgan• 5 years ago

… 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 https://news.ycombinator.com/item?id=23553486 for some more details.

xyzzy_plugh• 5 years ago

Is this not simply stem darkening?

Stem darkening is basically necessary to some extent for most renderers, for multiple different reasons depending on the implementation, otherwise glyphs come out far too thin. There's no "right" answer here

vadfa• 5 years ago

There is a ClearType configuration wizard that allows you to make fonts a bit thicker. I recommend doing it as a counterweight to that, especially on high DPI displays.

rendaw• 5 years ago

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.

dwighttk• 5 years ago

Mac OS X When was this written?

Semaphor2• 5 years ago

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.

jeroenhd2• 5 years ago

Your subpixel rendering settings need to align with the pixel layout of your monitor. Trying to smoothen text with a left-to-right BRG subpixel algorithm on a top-to-bottom GBR monitor, for example, will always look ugly.

On Windows you can tune this for ClearType (I don't know the exact command, I usually just type "ClearType" into the start menu) and doing a test similar to what you would get in the optometrist's: a set of texts, and you pick which one is the best and if things get better or worse.

If you have issues with blurry text, it could also be because of filters your monitors apply. Some using some kind of sharpering algorithm. Trying to tune the blurry monitor using some of the available websites might not be a bad idea in that case.

Semaphor2• 5 years ago

It was the screenshot of the rendering. As far as I know, ClearType has no influence on that?

causi• 5 years ago

mobile devices don’t use subpixel rendering due to having to suport both vertical and horizontal screen orientations

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.

bogwog• 5 years ago

I came to the comments just to ask about this part. Pretty much every desktop OS out there allows you to change the orientation of your monitors, and I haven't noticed any font rendering issues when doing so.

A citation for that statement from the OP would be appreciated.

jeroenhd2• 5 years ago

feel free to use it to fix custom font rendering on Windows

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.

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.

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.

avianlyric• 5 years ago

Funnily enough, Apple disagreed withtthis author and changed the way their subpixel algorithm worked years ago, so the author's preference clearly wasn't what the majority were expecting.

Apple only changed it due to the prevalence of “retina” displays. When the pixel density of your screen is high enough, sub-pixel rendering stops making sense (your normal pixels are already small enough). You can just apply normal anti-aliasing and get the same result.

This also has the advantage to remove all the super special font rendering code from your code base, no need to percolate font data through your entire rendering pipeline, just so you can do sub-pixel rendering in your final compositing and scaling step. Just push normal pixels, and treat everything the same.

All of this doesn’t change the fact there might be situations where sub-pixel rendering still makes sense. It’s just the OS X no longer supports it.

nerdponx• 5 years ago

All of this doesn’t change the fact there might be situations where sub-pixel rendering still makes sense. It’s just the OS X no longer supports it.

Is that why fonts all look bad when I plug an external monitor into my Mac?

lloeki• 5 years ago

When the pixel density of your screen is high enough, sub-pixel rendering stops making sense

I wonder if the prevalence of Retina displays across the Apple product line coupled with the prevalence of rotatable displays from iOS devices made them go towards something consistent across the board:

because 90deg rotations really doesn't play well with subpixel rendering, doubled down by having to handle four different orientations with a single font and have it display consistently on a single device, it makes sense to go with simplicity and walk the antialiasing route, and since you have Retina basically everywhere, well, just flick the switch everywhere as well.

I seem to recall (years ago, so memory may fail me) some blog post explaining how dropping subpixel rendering also allowed for some major cleanup in the Cocoa/CoreSomething rendering code.

mschuster91• 5 years ago

And then you get the exact opposite problem of macOS people trying to force macOS rendering onto other platforms because they prefer it.

This is not a matter of preference but of measurable quality. Fonts on macOS look super smooth, and most Windows laptops these days still ship with 1920x1080 displays which even with Cleartype enabled just looks like shit.

Linux is even worse, compared to a Mac a Linux desktop just looks like straight from the 90s (which is when most stuff regarding rendering seems to have frozen in time).

People using Macs generally value aesthetics, optical polish, UI consistency and elegance, a factor that is sadly lacking in the Windows world (there are ... five different ways of creating UI applications at least, six different applications to look for basic system configuration, ...) and completely absent in the Linux world (as a result of everything relating to Desktop Linux being underfunded and done by volunteer developers without UX design people).

BunsanSpace• 5 years ago

Linux is even worse, compared to a Mac a Linux desktop just looks like straight from the 90s

What are you smoking? most modern Linux distro's out of the box have the best font rendering of all OS's. Sure if you install some bare bones openbox DE it will look bad, but Gnome and to a less extent KDE look night and day better than windows and macOS.

flenserboy2• 5 years ago

It's weird when you run into people who prefer the spindly, rickety-looking fonts on Windows.

NoGravitas2• 5 years ago

I use both Windows and Linux on a regular basis, and I have to say that font rendering on Linux is almost always much better than on Windows. I frequently notice and am bothered by font rendering on Windows, even after running the ClearType tuning tool on both of my monitors.

whywhywhywhy• 5 years ago

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.

BlueTemplar5• 5 years ago

Spellchecking is browser-wide ?

jonhohle• 5 years ago

On macOS (ne OS X) system wide spellcheck has been available for over a decade.

zeta0134• 5 years ago

Not if a react component is reimplementing a textarea with JavaScript, which I've encountered in some enterprise apps. It's mildly infuriating, and breaks in lots of subtle ways.

ryandrake• 5 years ago

Thank you. This is the solution. Stop "fixing" my scroll bar. Stop "fixing" my copy/paste behavior. Stop "fixing" my default fonts. Stop "fixing" navigation from element to element using tab. Stop "fixing" what links look like, what happens when I right-click, what happens when I use my mouse wheel, what happens when I resize my browser window. Just stop trying to be clever. Deliver your damn hypertext to my browser, get out of the way, and allow it to render.

syntaxfree• 5 years ago

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.

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.

BlueTemplar5• 5 years ago

Hmm, have all designers that used to work with DOS (and similar) already retired ?

selfhoster11• 5 years ago

Windows classic themes have been a thing until the end of Windows 7. You could easily use whichever colours you wanted with these.

ribit3• 5 years ago

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?

thih9• 5 years ago

I guess the point is not sub pixel rendering itself, but having text that is as smooth as possible. I’d ask: why not?

Eric_WVGG2• 5 years ago

My understanding is that on pre-retina displays, subpixel anti-aliasing was a fairly difficult, complex, and resource intensive technique that resulted in huge improvements in readability, and in the era of retina displays, it is a lot of complication that results in barely perceivable gains.

ribit3• 5 years ago

Well, the point is that traditional display technology had limited spatial resolution, which is exactly why algorithms like subpixel rendering were created — to improve the visual fidelity of text on an imperfect screen. The algorithms themselves are not without drawbacks — sensitivity to background colors, implementation complexity, caching cost, scalability etc. If the spatial resolution of the display is high enough that the font looks smooth with "normal" rendering, why bother with complex workarounds?

gwbas1c• 5 years ago

Depends on screen size.

FWIW: I can see aliasing on subtitles on my 70" 4k TV, sitting a few feet away. I have excellent eyes.

ribit3• 5 years ago

A 4K 70" TV is hardly a HiDPI screen...

defanor• 5 years ago

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).

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).

indymike• 5 years ago

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).

haroman• 5 years ago

It's different for each browser's rendering capabilities.

Eric_WVGG2• 5 years ago

This article should be suffixed with “(2012)”.

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.

Also I could be mistaken but I believe as of about four years ago subpixel was dropped from Macs altogether.

asadkn• 5 years ago

MacOS dropped subpixel AA in Mojave by default but brought back a stronger default of grayscale AA in Big Sur AFAIK, which can be optimized. [1]

And I agree, a lot has changed since the article was written. On HiDPI displays, personally I don't like subpixel antialiasing.

[1] https://www.reddit.com/r/MacOSBeta/comments/jiwwga/big_sur_f...

zajio1am• 5 years ago

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.

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.

yupyup54133• 5 years ago

I always use the links terminal browser test. If the site is usable in my terminal with the `links https://usabilitypost.com/2012/11/05/stop-fixing-font-smooth...` 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!

butz• 5 years ago

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. https://gitlab.gnome.org/GNOME/gtk/-/issues/3787

Please Stop “Fixing” Font Smoothing (2012)

Related Stories