[cairo] Sub-pixel Font Filtering in 1.10

[Lance Hepler]

Hi Freddie,

> On Tuesday 12 January 2010 21:52:34 Brandon Wright wrote:
> > Lance Hepler's patch
> > (http://lists.freedesktop.org/archives/cairo/2009-February/016494.html)
> > doesn't require any more external support than cairo needs now, and
> > this is the same approach Qt has taken.
>
> I would object the committal of these patches. How the font back-end chooses
> to filter the text it renders is its prerogative --- it is none of Cairo's
> business.

Freddie, generally I agree with you. However your arguments here
demonstrate that you are unfamiliar with the relatively recent history
of subpixel rendering in cairo.

A disclaimer in advance: These are my interpretations of the facts. I
do not wish to put words into the mouths of any developer, for any
project. If I am wrong, please correct me.

> The above patch is a nightmare for several reasons.

>  1. It makes it harder for distributions to disable sub-pixel rendering --- a
> patented technology. Hence distributions wishing to respect software patents
> need a simple way to remove all infringing code. If libraries use the FreeType
> API then this only needs to be done in one place. (When compiling FreeType ---
> no API breakage either.)

1) The cairo developers do not share the freetype developers' patent
fears. They simply ignore this point. (I might be wrong here..)

2) As for API breakage, the API is broken. If freetype disables its
SPR, then it _silently_ fails to produce SPR text when asked. The
cairo developers regarded this as unacceptable. Prior the 1.8 release,
David Turner's freetype work was present in cairo , but because Fedora
disables SPR, cairo would silently fail vast swaths of its test suite
and they found this unacceptable. The patches were reverted and
another solution was asked for.

3) Behdad has some plans for the way the font backend works. Something
to do with perfect scalability. As I understand it, this is difficult
to achieve if we pass the font rasterization task to freetype.

>  2. If the filtering coefficients (which are empirical) change in FreeType these
> patches will also need to be changed. It is code duplication at best.

Agreed.

> Please see David Turner's Cairo patches which make use of the FreeType API.
> (And out of all of the patch sets I've come across are the only ones I
> consider to be correct from a technical standpoint.)
>
> The reason we are in this mess at the moment is because the Xft developers
> decided to perform sub-pixel rendering themselves (as opposed to helping
> design an API for FreeType). Lets not make the same mistake twice :)
>
> > Apple has options for linear 3 and 5-tap FIR filters, and calls them
> > "Light" and "Medium." I believe the early patches for Cairo had
> > similar names in their implementations as well. Regardless, Fontconfig
> > already has these options and calls them "lcddefault" and  "lcdlight"
> > with the config Cairo currently uses called "lcdlegacy." It's
> > important to understand that no one's talking about exposing these
> > settings in the Cairo API--just providing complete configuration for
> > the font backend. It's irrelevant what you call them inside Cairo
> > because these settings are already named and widely used with
> > Fontconfig, Qt, and third-party patches. The only person who's going
> > to see what they're called is whoever is working on the Cairo
> > internals.
>
> Apple no longer provide such options --- they were removed with the release of
> Snow Leopard (10.6). Moreover, I am not totally convinced that the options
> were 3- and 5-tap filters respectively (or what the coefficients were). Since no
> behaviour was ever formally specified (just listed as "Font smoothing" it would
> be fool-hardly to depend on it.
>
> Finally, I do not believe that there options were ever exposed by a per-
> application public-API.
>
> Polemically yours, Freddie.

Lance