Text anti-aliasing on the Mac

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?  (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?

~TJ

Received on Monday, 1 October 2012 18:06:59 UTC