[cairo] Sub-pixel Font Filtering in 1.10

[Freddie Witherden]

On Friday 15 January 2010 23:56:15 Carl Worth wrote:
> On Fri, 15 Jan 2010 19:09:38 +0000, Freddie Witherden 
<freddie at witherden.org> wrote:
> > <Rant>
> > Moreover what is *any* test suite for Cairo doing relying on the pixel
> > output of FreeType!?! Even minor releases of FreeType (e.g., 2.3.9 ->
> > 2.3.11) change the pixel output for given fonts at different sizes. It is
> > one of the main advantages of the auto-hinter --- that it can be improved
> > retroactively. Any test suite relying on non-invariant properties of
> > other libraries deserves to break. Regularly.
> > </Rant>
> 
> We rely on the pixel output of cairo, because pixel output is the only
> thing we've been able to come up with for verifying that cairo
> works. When freetype, (or ghostscript, or poppler, etc.), change, then
> the "correct" results of the test suite change as well. That's annoying,
> but we haven't found a way to avoid that and still get the testing we
> want.
> 
> So for now, we document the various versions of the various
> rasterization tools that are used to generate the "correct" results from
> the test suite. And yes, this does impose a fair amount of burden on
> someone trying to get the test suite to pass without errors.

Right! Now I'm with you. So for text which requires FreeType (and unsuitable 
for the Cairo font) would it be possible to detect if FT was compiled with LCD 
support and if not used an alternative set of reference images. Or, just to 
disable sub-pixel rendering entirely? Would this then fix the Fedora breakage?

> > However, DIY rasterisation is seldom a sound idea and is likely to
> > alienate users. (Consider Safari on Windows, a case study I cover in my
> > article or the Qt OpenGL back-end, whose text output is often condemned
> > by users.)
> 
> At which point do you see the transition from DIY to simply being part
> of the system? It's hard for me to find text on my current system that's
> not rendered with cairo. (Though I won't claim that I don't have an
> unbiased set of applications.)

If I were put on the spot I'd say that 75% of text on a modern Linux desktop 
(i.e., the most recent version of a popular distribution) is rendered via 
Cairo. The rest is Qt, with a small fraction using Xft (GNU Emacs 23 and Qt3 
come to mind). As Qt is used by KDE there are a reasonable number of desktops 
whose text is rendered almost exclusively by Qt. (And while games often do 
roll their own solutions people are seldom as concerned about in-game text.)

In this scenario I would say DIY => system transition occurs when both major 
toolkits switch to it. Currently, most Linux desktops have obtained 
consistency: both use FreeType for rasterisation and Fontconfig for 
configuration. On the system I am writing this message on text rendered by Qt 
is pixel-perfect with that rendered by Cairo.

(As another aside: when Qt 4.0 was being developed (moving away from Xft) the 
first iteration of the raster image back-end (similar to that of Cairo's image 
surface) was developed it rendered all text as painter paths. The results 
spoke for themselves (a facsimile of which is available as part of a Qt labs 
blog post) and the final release delegated rasterisation to the systems 
library.)

Polemically yours, Freddie.