Re: Text anti-aliasing on the Mac

Tab Atkins wrote:

> More investigation into this issue has shown that the problem is
> different than what I explained at the start of the page.  It's not
> *really* about the AA.  However, a proprietary property we have
> (-webkit-font-smoothing) which lets you switch between AA modes
> *also* has the effect of turning hinting on or off.  Chrome 22
> changed that, so that it no longer had this side effect.

Tab, can you provide some simple examples with screenshots to
illustrate what you're talking about here?  I think you're mixing up
hinting/rasterization/shaping but I can't quite tell from the language
you're using.

The -webkit-font-smoothing property is basically a way of directly
accessing controls that are CoreGraphics specific (i.e. OSX specific).
What do they do for Chrome on Windows, where the underlying
rasterizer used (GDI) isn't the same?  There are rough equivalents but the
results are *not* the same.

What do you mean by hinting here?  I think you're confusing the
rasterization of the outlines and their adjustment via hinting
instructions.  In general, the OSX rasterization is heavier than the
GDI rasterization of the same outline. Hinting instructions are
generally ignored on OSX but are used in GDI and DirectWrite.

> I'm still investigating the problem in more detail, but it seems
> like the "dilation" of text that makes it look fat and bold is an
> intrinsic property of the Mac's hinting engine.  That's why, back
> when "-webkit-font-smoothing: antialiased" turned off hinting, it
> solved people's problem - the text now looked like it did on other
> platforms (not fat).

> roc, does your always-on text shaping mean that you do your own
> hinting, rather than relying on the system to do it for you?  If so,
> that would explain why Firefox hasn't had to deal with the issue -
> it simply doesn't exist there!

As roc said, Firefox does uses platform font rasterization, we use an
API that basically looks like this:

  ShowGlyphs(glyphs, positions)

where glyphs are the glyph ids from the font and positions are
specific (x,y) coordinates that may include fractional pixel
placement.  Shaping is basically the process of creating those two
arrays.  Different platform API's may or may not allow fractional
placement, GDI for example doesn't.

The big problem with trying to "standardize" any sort of property at
the CSS level is that font rasterization varies based on the
underlying platform API's used.  So for the same font, it may appear
"thick" on OSX but "thin" under DirectWrite (GDI rasterization is
generally in between).  Under Windows this is also affected by the
hinting style used when designing the font, fonts like Arial and
Georgia are very different from fonts like Cambria and Constantia.

In general, the desire for authors to be able to control rasterization
parameters is fraught with problems because there isn't one canonical
way to rasterize fonts and users on differ platforms are accustomed to
*very* different font rasterization (e.g. Windows XP vs. OSX).  In
general I think it's better to advise authors that they can't control the
subpixel precision of text rendering across platforms.



Full background on the problems/issues involved with font rasterization

Received on Wednesday, 3 October 2012 03:24:02 UTC