Re: A property for font antialiasing control on Mac OS X

Simon Fraser wrote:

>> The most significant use case for author control is that while
>> subpixel antialiasing (on all platforms) often provides the best
>> results for body text [2], its implementation on Mac OS X has a
>> tendency to make light text on a dark background overly or even
>> unreadably bold [2].  This problem is fully cross-browser on Mac OS
>> X, in that all browsers on Mac OS X using the native text
>> rasterization code (all major browsers, I believe) run into this
>> problem.  In other words, there are many cases where subpixel AA is
>> preferable, but also a number of cases where it produces very bad
>> results that authors want to avoid.
> 
> I understand your argument that the main reason this property exists
> is because of this "extra weight" problem on Mac. We (Apple) are
> aware of this issue.
> 
> However, it would surprise me if authors didn't also want control
> over sub pixel- antialiasing itself.
> 
> I did a quick test on Windows, looking at IE10 and Firefox, with
> ClearType enabled on the system. In a test case involving a 3D
> transform and opacity, Firefox applied subpixel-AA to only some of
> the elements on the page. IE 10 seems to disable ClearType for all
> web content, even though it was enabled for other UI in the system.
> 
> So clearly, even without the Mac problem, subpixel AA differences
> exists on non-Mac platforms, and I suspect that discerning web
> authors would want control over it.

Authors may *want* to pixel-level control over subpixel AA but
that's a separate issue from the OSX light-text-on-dark-background
bug. I think that generalized, author-level control over subpixel AA
is both a bad idea and impractical.  It's a bad idea because the use
of subpixel AA is a *user* level preference, especially in Windows
environments where ClearType can be tuned to what a user prefers. 
It's impractical because the precise meaning of "subpixel AA" varies
depending upon the OS/backend used (CoreGraphics, FreeType, vanilla
GDI, ClearType GDI, ClearType DirectWrite) so there's really no simple
way to specify property values that will be consistent across
platforms.

In general, subpixel AA is a "best effort" enhancement used by
OS-level API's to make text more readable.  Especially in situations
where some form of compositing is required (opacity, transforms, etc.)
it's often difficult to support subpixel AA without low-level access
to the font rasterization layer because it involves carrying around
three-channel alpha information and not all OS-level API's provide
that.  That's why the use of transforms or opacity may result in user
agents reverting to grayscale AA instead of some form of subpixel AA.
The same is true if the OS doesn't understand/support a given monitor
(e.g. an external monitor of unknown capability) or a given
configuration (e.g. a monitor tilted upright).

Authors have been using "-webkit-font-smoothing" to work around the
problem OSX CoreGraphics has with rendering light text on a dark
background. This is really just a band-aid, it would be ideal if this
was fixed at the OS-level but as this hasn't happened, so for Firefox we
need to figure out a way of allowing authors to workaround this
problem so that text rendering is consistent across user agents under
OSX.  This leaves us with a narrow range of options:

  1. recognize "-webkit-font-smoothing: antialiased" and use it to
     switch to grayscale AA text rendering only under OSX
  2. recognize "-moz-font-smoothing: antialiased" and use it to
     switch to grayscale AA text rendering only under OSX
  3. recognize "osx-font-smoothing: grayscale" and use it to
     switch to grayscale AA text rendering only under OSX
  4. specify "font-smoothing" as a general property and 
     define what that means for all possible OS/backend combinations

David is proposing (3) and Simon seems to be advocating for (4). 
But I don't think a general "font-smoothing" property (4) is
either desirable or practical.  Proposal (3) has the advantage
that authors would hopefully be able to use a single, unprefixed
property to implement this band-aid across browsers.  Proposals (1)
and (2) are crappy from the perspective of eliminating prefix usage
but are *much* more expedient.

Regards,

John Daggett

Received on Thursday, 25 July 2013 02:53:28 UTC