Re: Text anti-aliasing on the Mac

Special thanks to Ben Wagner for explaining the problem in detail!

On Mon, 01 Oct 2012 20:06:11 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> If you've been following some of the kerfuffle about Chrome 22's
> release to the public channel, you may have heard about our issues
> with text on the Mac.  This requires some explanatory exposition, so
> buckle up.
>
> There are two basic modes for anti-aliasing text: "grayscale" and
> "sub-pixel"/"LCD".  Grayscale anti-aliasing is simple - if a glyph
> outline only fills a portion of a pixel, color the whole pixel with a
> partially-transparent version of the text color, then blend it with
> the background as normal.  For black text on a white background, this
> gives it a slight gray border, thus the name.  LCD anti-aliasing is
> more complex; it varies the intensity of the individual r, g, and b
> components of the hardware pixel to attempt to more accurately render
> the exact outline.  Most people consider the results of LCD
> anti-aliasing to be superior, but it has some limitations.  Given the
> shape of the subpixel components on LCD monitors (tall, thin
> rectangles), you can only do this kind of anti-aliasing on text that
> is straight horizontally aligned - any rotation breaks it.  As well,
> it's incompatible with the optimizations browsers do on many elements
> to "hardware-accelerate" drawing - if the element is partially
> transparent, or is 3d-translated, or a few other switches that cause
> the element to render in an independent layer, you can't do LCD
> anti-aliasing, as you need to know the color of the background before
> you can tell how you should tweak the rgb components.
>
> Because LCD anti-aliasing is superior, we tend to use it for normal
> text, but we have to switch to grayscale anti-aliasing when we run
> into one of its limitations.  On most platforms, this is hardly
> noticeable, and so not a big deal.  However, Macs are different - the
> system's native text drawing engine implements LCD anti-aliasing
> somewhat uniquely, dilating the outlines of the text rather
> significantly.  This means that when we switch from LCD to grayscale,
> you see a big change in the apparent weight of the text.  This is
> obviously undesirable - fading in an element from opacity:0 to
> opacity:1, for example, will cause a sudden "pop" at the end when the
> text changes appearance.
>
> Previously, Chrome had some properties that incidentally switched text
> to grayscale anti-aliasing, which people used to avoid this pop.  As
> well, some designers simply dislike the "fat text" effect that LCD
> anti-aliasing causes on Macs (particularly in their heading fonts,
> which looked bold on Mac but normal elsewhere), and so used these
> properties to switch to grayscale anti-aliasing in general.  Chrome 22
> changed the behavior of some of these properties so that they no
> longer switched the anti-aliasing to grayscale, which caused a lot of
> people to complain.  We're reverting this change for now, but we still
> have the unsolved problem of the "pop", and designer's general desire
> to avoid "fat text".
>
> So, I bring this to you, the WG.  How do Firefox and Opera deal with
> this?

We don't. :) We have more or less the same issue as you on Mac OS X. On  
other platforms (I'm on Linux, my Windows VM is broken atm) it's  
noticeable to pedants like me, but it's subtle enough. So no  
paradigm-shifting evidence from us, but I have a few thoughts:

> (IE, you get a pass this time.)  Safari, any opinions?
>
> One of our devs tried to deal with this by actually implementing SVG's
> "text-rendering: geometricPrecision;" property value, which strongly
> implies that its effect should be to turn off hinting, and making it
> also force grayscale anti-aliasing, with the justification that it
> makes the text shapes more geometrically precise on the Mac.  I
> objected to this change, because you don't want hinting to turn off in
> general.
>
> If there is some smart way to handle this, I'm all ears.  Otherwise, I
> might recommend we simply add a proprietary property that solves this
> specific problem, forcing text on Mac to use grayscale anti-aliasing,
> and have no effect on other platforms.
>
> Note that this is not an issue on Retina displays - when you have 2x
> DPI you can get great results from the much cheaper grayscale
> anti-aliasing, so there's no reason to use LCD at all (I think we turn
> off hinting too, for the same reason).  However, it seems that we
> can't just wait out the issue.  It *does* mean, though, that however
> we solve it will likely be just a temporary patch (which makes the
> "silly proprietary property" approach seem more appealing).
>
> Thoughts?

Correct me if I'm wrong – I'm still a noob as far as text rendering goes –  
but we seem to be working around a bug in Mac OS X. Or rather, a feature  
that is sometimes buggy: tiny font sizes need the dilation in order to be  
legible, but larger sizes look "ugly" or at least different. Thus it may  
be short-sighted to codify behavior implied by _some_ of today's  
technology and customs.

My take is that it's up to the implementations to take such  
platform-specific behaviors into account. Those of us that develop UAs for  
platforms like the Mac could switch rendering modes at sizes when the  
disadvantages of dilation outweigh the benefits.

It's completely understandable that authors want to control this major  
aspect of how their page looks using a CSS property. But since many  
(though probably not most) people care a lot about how text on their  
system is rendered, it seems a bad idea to let the author override the  
user's choice (which this dilation feature to a certain extent is – I'm  
not sure how well-exposed the setting is on the Mac though).

-- 
Leif Arne Storset
Layout Developer, Opera Software
Oslo, Norway

Received on Wednesday, 10 October 2012 10:57:55 UTC