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

On Thu, Jul 18, 2013 at 12:23 AM, Simon Fraser <smfr@me.com> wrote:
> On Jul 17, 2013, at 2:57 pm, L. David Baron <dbaron@dbaron.org> 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.


I can confirm this.  On Windows, at least, we have had issues with
some fonts on extremely small font sizes (think: <= 6pts) and had to
turn off anti-aliasing completely using '-webkit-font-smoothing:
none'.  There are also some cases in our application where we want to
choose between ClearType and grayscale AA, regardless of the user's
Control Panel settings, to give our visual designers better aesthetic
control on a per-element basis (however, this is a desktop application
use-case, not a Web use-case).

Unfortunately, setting '-webkit-font-smoothing' didn't work on
Windows, so we had to patch our chromium fork to implement it.  There
was a WebKit bug for this [1] where this patch is uploaded, but it
looks like it got 'WONTFIX'd around the time the Blink fork was made.

Best,
Shezan

[1] https://bugs.webkit.org/show_bug.cgi?id=86776

Received on Thursday, 18 July 2013 09:33:42 UTC