[cairo] Discussion: LCD Filtering API
nlhepler at gmail.com
Wed Jan 28 19:28:26 PST 2009
This discussion is related to freedesktop bug #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
FT_LCD_FILTER_NONE, FT_LCD_FILTER_DEFAULT, FT_LCD_FILTER_LIGHT,
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
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo