[cairo] Sub-pixel Font Filtering in 1.10
Freddie Witherden
freddie at witherden.org
Fri Jan 15 16:22:19 PST 2010
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.
More information about the cairo
mailing list