[cairo] Discussion: LCD Filtering API

[Behdad Esfahbod]

Lance Hepler wrote:
> Hi Behdad,

Hi Lance,

> That's a very interesting plan. I can understand its usefulness for
> cross-platform consistency. And I don't mean to attack your hard effort,
> but is that really practical?

I'll make it be :P.

> Each platform (Windows/Mac/*nix) has its
> own font-handling stack, and in the case of the two former, a certain
> look-and-feel of the font rasterization (Cleartype/Whatever-Apple-does)
> that is native to each platform. Users of these platforms sort of expect
> consistency in the font rendering, and moving all the rasterization into
> cairo would make it harder for developers to build applications on these
> platforms that "blend in" with the native environments. Is that sort of
> behavior desirable? I mean, I realize having consistent behavior between
> platforms is desirable, but I am uncertain as to the usefulness in this
> case.

Sure.  Very good point.  The main reason I have to start rasterizing fonts in
cairo itself is to get truly linearly scalable fonts.  See:

  http://lists.cairographics.org/archives/cairo/2008-May/014149.html

Currently, the win32 and quartz backends do the show_glyphs() operation
natively so they don't even rasterize glyphs and pass them to cairo.  I
imagine in the future we will be going through the cairo rasterizer and
filtering if and only if any of the font options is set to anything other than
DEFAULT.  Something like that.  That will keep both fronts happy.  Or I hope
so :).

> Also, I don't know how David would feel about ripping the lcd filtering
> code from Freetype and putting it into a separate library. Code
> duplication and all that jazz.

The filters are extremely simple.  We're talking about a few hundred lines of
code at most.  I originally wanted to do the rasterization in cairo then
delegate to FreeType to do the filtering but David suggested that we simply do
the filtering ourselves.  Which makes sense given how easy it is.  I
personally prefer keeping it in one place, but sometimes it's plain less
overhead to duplicate.  Oh well...

> But should I instead start working on
> some patches that take the filtering code from Freetype and moves it
> into cairo?

I wouldn't rush.  I first need to go implement the rest of the bits pointed
out in my email referenced above, then get to filtering.  I don't expect that
to happen for 1.10.  Hopefully 1.12.

Cheers,

behdad


> Thanks for the feedback,
> 
> Lance
> 
> On Wed, Jan 28, 2009 at 10:39 PM, Behdad Esfahbod <behdad at behdad.org
> <mailto:behdad at behdad.org>> wrote:
> 
>     Hi Lance,
> 
>     I agree with most of your positions.  However, my long term plan is
>     to move
>     glyph rasterization away from FreeType and into cairo, and that includes
>     subpixel rendering.  I think the API should wait till that happens.
>      In that
>     case Carl's remaining issues will be moot as we can do the same
>     filtering on
>     all platforms and it will not be FreeType-specific anymore.
> 
>     behdad
> 
>     Lance Hepler wrote:
>     > Gentlemen,
>     >
>     > This discussion is related to freedesktop bug #10301
>     > (http://bugs.freedesktop.org/show_bug.cgi?id=10301).
>     >
>     > Carl has suggested we have a discussion as to how cairo should handle
>     > lcd filtering if it is patched to utilize freetype filtering. Freetype
>     > provides 4 options,
>     > FT_LCD_FILTER_NONE, FT_LCD_FILTER_DEFAULT, FT_LCD_FILTER_LIGHT,
>     FT_LCD_FILTER_LEGACY.
>     > These correspond to no lcd filtering, a FIR5 filter, a FIR3
>     filter, and
>     > an intra-pixel filter like the one cairo currently employs. The most
>     > current version of the patch can fallback to cairo's original
>     > intra-pixel lcd filter in the event that freetype has had these
>     options
>     > compiled out (as they are by default, due to patent concerns) or are
>     > unavailable in that version of freetype.
>     >
>     > Carl has cited something of a combinatorial settings problem, where
>     > cairo already exposes 3 antialiasing options and 4 hinting options,
>     > making for 12 combinations currently. Adding another 4 lcd filtering
>     > options for the subpixel case makes for a total of 24 options.
>     Should we
>     > expose all these options to the user? Should there be a dialog for
>     cairo
>     > that exposes these options? Or should we limit the number of
>     options, or
>     > reassign the defaults based on what type of hinting is being used (the
>     > concept of sensible defaults)? These are all good questions. I'll
>     voice
>     > my opinions on these questions one at a time:
>     >
>     > 1) Should we expose all these options to the user?
>     > I think we should. Cairo is a library first, and having more options
>     > available to developers doesn't hurt them, as long as the behavior of
>     > each option is well-documented. In the case a developer doesn't
>     want to
>     > worry about it, we should have sensible defaults. (point 3)
>     >
>     > 2) Should there be a dialog for cairo that exposes these options?
>     > Cairo's a library. It's not a settings interface like fontconfig.
>     > Distros currently use fontconfig to manage these settings, so I think
>     > they should continue to. GNOME provides a dialog, KDE has a dialog, Qt
>     > has a dialog as well. I'm not familiar with a similar dialog for
>     Cairo,
>     > but it seems silly to try and have one for what is a drawing library
>     > (not even a widget library). As long as the settings are exposed
>     in the
>     > API, that is sufficient. Let the user-visible endpoint be
>     concerned with
>     > whether and how they want to expose those options.
>     >
>     > 3) Or should we limit the number of options, ...?
>     > I don't think we should limit the number of options, because it's
>     all a
>     > matter of preference and these sorts of things can be very subjective,
>     > and people can have very strong opinions. The rendering of text on a
>     > computer can be a very heated issue, because it's how we primarily
>     take
>     > in and produce information, and the eyeballs can be strained by such
>     > things. I for one couldn't really use a Linux desktop till these
>     better
>     > filtering methods came about because the old ways actually caused
>     me to
>     > strain my eyes and get a headache. But I have bad eyes, and am really
>     > sensitive to these things.
>     >
>     > 4) ...or reassign the defaults based on what type of hinting is being
>     > used (the concept of sensible defaults)?
>     > I think this will require a protracted discussion. Obviously, if
>     > freetype is unavailable then cairo's default intra-pixel filter
>     will be
>     > used as the fallback. If freetype can filter, then I do suggest we use
>     > the FIR5 filter as a sensible default (for UNHINTED/SLIGHT hinting),
>     > since it can produce such nicely-shaped text. For the strongly hinted
>     > case, I don't really know, and don't have any strong opinions. I don't
>     > particularly like strongly hinted text, especially since freetype's
>     > FIR5/FIR3 filtering can make the (IMHO) better-shaped unhinted or
>     > slightly-hinted text so readable. But if people seem to prefer the
>     > LEGACY filter for medium/strongly-hinted text then I think it
>     should be
>     > the default under those hinting modes.
>     >
>     > That's all I have to contribute at the moment.
>     >
>     > More questions and more opinions are welcome. Lets get this ball
>     rolling!
>     >
>     > Thanks everyone,
>     >
>     > Nicolaus
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > cairo mailing list
>     > cairo at cairographics.org <mailto:cairo at cairographics.org>
>     > http://lists.cairographics.org/mailman/listinfo/cairo
> 
>