[cairo] Sub-pixel Font Filtering in 1.10

[Brandon Wright]

On Tue, Jan 12, 2010 at 2:44 PM, Carl Worth <cworth at cworth.org> wrote:
> On Sun, 10 Jan 2010 02:13:58 -0600, Brandon Wright <bearoso at gmail.com> wrote:
>> I'm curious to know whether anyone has thought about including proper
>> support for sub-pixel font filtering in 1.10
>> (https://bugs.freedesktop.org/show_bug.cgi?id=10301).
>
> I'm really confused when I see comments like yours describing "proper
> support for sub-pixel font filtering".
>
> I've been using cairo with sub-pixel rendered font rendering for
> ages. But one might read your query in a way that suggests that cairo
> doesn't have this feature at all, which would not be accurate.
>
> Now, there is a low-level implementation detail, (the actual filtering
> used when doing sub-pixel rendering), that some people have wanted to
> change.
>
> 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).

Do I need to repeat that this is just intended to expand Cairo's
support for the hinting configurations in Fontconfig? It's not going
to require any freetype-specific features. Lance's patch doesn't use
the freetype filtering API.

> 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).

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.

> 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).
>
> 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.
>
> I'd propose some here, but I can't come up with anything better than
> CAIRO_LCD_FILTER_POORLY_HINTED_FONT_TO_NOT_HAVE_OBJECTIONABLY_BAD_COLOR_FRINGES

You're being very non-objective. Not everyone can tolerate having only
a very limited set of pixel-grid-aligned, byte-code-hinted fonts  that
have significant shape distortion and improper stem widths. The
poorly-hinted font (in your opinion) is often better-hinted (or not
hinted) and only suffers from "bad color fringing" because the the
current filtering implementation doesn't balance the color energy at
all--it just clips any filtering at the pixel-boundary. The byte-code
hinted fonts don't exhibit the color fringes only because any
sub-pixel rendering with them is generally limited to tiny one-pixel
corners.