[cairo] Sub-pixel Font Filtering in 1.10

[Freddie Witherden]

On Tuesday 12 January 2010 20:44:03 Carl Worth wrote:
> Cairo currently has its own code for this filtering, and recently
> freetype has grown support for *its* own filtering, (with several
> different variations---one of which I believe is identical to what cairo
> is doing today).

Correct. FreeType has a three tap FIR filter called 'light' (which does very 
little due to the choice of coefficients), a five tap FIR filter called 'default' 
(which performs some neat Gamma correction in the process) and a 'legacy' 
filter which is the same as the one used by Cairo and Xft.

> And, yes, we have thought about adding support for the user to be able
> to configure that in one way or another. The only concrete proposals
> I've seen for that have involved very freetype- and algorithm-specific
> names for the filtering which I found unacceptable. The proposed names
> were things like "fir3" or "fir5". I don't like these names for several
> reasons:
> 
>   1. They hint at the low-level details of the filtering---such as being
>      implemented with a 3- or 5-tap FIR filter. But if there's a
>      user-level configuration option here, it should actually describe
>      the high-level qualitative behavior being configured. I haven't
>      seen a description of that.
> 
>   2. The names such as "fir3" and "fir5", while already being too
>      specific (as described above) or also insufficiently specific. They
>      don't at all capture anything about how the actual filter-tap
>      values were determined. And that's the most essential part of the
>      filter design. The filter values represent a tradeoff between using
>      color-channel values to represent "shape" and "position" to achieve
>      an acceptable-looking result that achieves as faithful a
>      representation of the desired shape with minimal color-fringing
>      artifacts. And names like "fir3" and "fir5" say nothing about that.
> 
>   3. The proposed names are freetype-specific and are of no use if
>      applied to a font system other than freetype. (See a recent mail
>      that says that existing configuration such has HINT_SLIGHT and
>      HINT_MEDIUM that is already in cairo is already too
>      freetype-specific).

I agree on all three points. However, Fontconfig knows the filters as 'light', 
'default' and 'legacy' and Qt (>= 4.5) respects the users choice of filter. The 
patches applied by the Ubuntu maintainers have a similar effect (i.e., respect 
Fontconfig).

Generally people will prefer the 'default' filter on account that it performs 
some cheap gamma correction to the text. This causes it to look 'blacker' than 
it would otherwise.

> Aside from the bad names, one of the primary justifications I've seen
> for changing the filtering is to render fonts with horrible hinting
> instructions (or systems with horrible hinting implementations) with
> less color-fringing. Personally, I see sub-pixel rendering as something
> that doesn't even make sense to do unless you've got a well-behaving
> system, (both font and hinting engine), in the first place.
> 
> So fixing up "bad" color fringing in a case like this is really just a
> band-aid for an entirely different problem. The better way to avoid
> color fringing in such a case is to just not use sub-pixel rendering,
> (or fix the broken font or hinting implementation).

It is not a band-aid at all. Cairo currently uses an intra-pixel filter taken 
from libXft. This filter is *technically inferior* to finite impulse response 
filter (FIR) which is used by: CoreText (OS X), ClearType (Windows), Qt (pre 
4.5) and FreeType (post 2.3 as an option). The FIR type filters are inter-pixel 
filters (so the filtering is performed across sub-pixel boundaries --- just as 
it should be).

The hinting argument is also heavily flawed; it is hinting itself that is a 
band-aid --- a hack from a time when anti-aliasing was not practical. The 
effect of hinting is to distort the outlines of glyphs --- and hence it *can 
not* be used when rendering freely scalable text, such as that in a PDF 
document. So if you want your system to be able to render PDF documents with 
sub-pixel rendering you need an FIR-type filter.

If one looks at a PDF document in Evince (and it has to be Evince, not Okular 
due to the way Poppler works) you're looking at un-hinted text rendered by 
Cairo. However, you'll also notice a lack of sub-pixel rendering (even if it 
is enabled for the rest of the system). One reason for this is because the 
default Cairo filter would awful colour fringes.

All modern operating systems are moving away from hinting, as of 2010. Apple 
ditched it back in 2001 with the release of OS X, Microsoft second with the 
release of the WPF (.NET, all text is freely scalable) and most recently with 
the release of DirectWrite. Hinting is, for all practical purposes, a dead 
end.

I discuss these hinting- and implementation-related issues at length in my 
article on font rasterisation:

 http://freddie.witherden.org/pages/font-rasterisation/

> That's just my opinion, of course, and we do sometimes provide
> configuration options to allow people to achieve different results in
> the face of different opinions. But to do that we really need
> configuration options that accurately describe what is desired.

Personally, I am not convinced there is a need to directly configure the sub-
pixel filter. (Unlike say with hinting and anti-aliasing where a sound 
technical case can be made for changing these --- such as when requiring 
freely scalable text.) Just respect Fontconfig and everyone wins.

Polemically yours, Freddie.