[cairo] more LCD Filter API discussion (LEGACY vs. DEFAULT)

[Tobias Wolf]

Salvete, my first post. This is a follow-up to Carl’s comment on bug 
http://bugs.freedesktop.org/show_bug.cgi?id=10301

Thanks for the points you make.

(In reply to comment #67)
> First, you seem to be largely arguing for a change in the default
filtering,
> beyond just adding code to allow for the freetype filtering to be
used. That's
> certainly a useful discussion to have. But oddly, the images on the
page don't
> actually show direct comparisons of the different choices we have here
for a
> default. I'd like to see the results of cairo's current code compared
to
> freetype's LEGACY and that compared to FIR3 and FIR3 compared to FIR5.
Things
> like that.

Yes, I do. Unfortunately my own points were dispersed across some posts
here¹ and on that page². And I agree that my comparison is not
exhaustive wrt the four modes. It wasn’t meant to be any-to-any. (You
can do that, i.e. an ABX test, by opening the attached Gimp file). 
The comparisons I do have are there for three reasons: 
* To disqualify LEGACY as a default filter. It sucks for unhinted and
lightly hinted. Always, so it’s out.
* To argue that FIR5 is a high quality filter suitable to be default.
* To show that light or no hinting should be the default assumption for
Cairo.

basic logic. 

FIR3 was not needed to demonstrate this argument. I can however add it
if that helps. Your original comment was that the Cairo-internal filter
was written with the assumption of pixel-fitting, and that this were
“good hinting”. I’m saying that’s a bad assumption, for Cairo.

> You also limit the presentation by saying "This is not a test of the
boring
> canonical high contrast scenario with bytecode hinted DejaVu Sans, 8pt
text,
> and pixel-fitted stems.". As "boring" as that scenario might be, it's
a
> terribly important one, so I would really like to see some examples of
that
> added if you would. I'd like to ensure a "do no harm" situation here.

Yes. I know that most Cairo text today is DejaVu Sans 8pt. But
fortunately this is entirely solvable by desktop integrators with some
smart fontconfig setup. If user requests “Best contrast” then enable
LEGACY, If user requests “Best shapes” then enable FIR5 or FIR3. But for
a generic drawing surface defaulting to the new filter is the best
assumption.

Let me remind you of Sylvain’s exhaustive test:
http://spasche.net/files/lcdfiltering . Some fonts work better with
certain setting combinations than others, contingent on their respective
geometry. But again, the new filter wins by virtue of being most
versatile and robust.

> Meanwhile, another problem I had with the original patch series was
that it
> simply exported all of the freetype filters as-is up to the user level
through
> cairo's public API. One problem with this is that the filters are all
obviously
> freetype-specific while cairo provides a cross-platform API. An
argument for
> providing the API is for someone like Behdad to be able to write a
> font-preferences dialog that presents (unnamed) font-rendering samples
to the
> user and lets them simply click on which one they prefer.

There are certainly more conceivable use cases of this API besides
generating these previews. I guess also Cairo usage on other platforms
would benefit from having access to their respective settings, whatever
technology they use and what modes they offer.

> But for that kind of font-preferences dialog, we already have 3
different
> ANTIALIAS font options and 4 different HINT_STYLE options. So that's
12
> different necessary samples now, and adding 4 different filters
expands that to
> 48, which seems to go way beyond what any user could ever want to see.

Sorry, but who would want to offer that? The sensible option
combinations would reduce the necessary previews to at most half a
dozen. All the others are simply incompatible. David Turner drafted a
font preferences dialog last year that would only allow good
combinations, all reduced to four main options. See here:
http://article.gmane.org/gmane.comp.lib.cairo/9347

> Meanwhile, the descriptions on your page seem to argue for specific
filters
> being best in specific situations. For example, there seems to be an
implicit
> preference for FIR5, (no FIR3 examples, and a link to an Ubuntu poll
favoring
> FIR5). So is there any reason to provide FIR3 at all?

Well, I’m sold on FIR5. To me the other one has more fringes and worse
shapes. But this could be different for the next guy. I see no need to
remove it.

> Also, you argue that
> LEGACY doesn't do well in anything but the strongly-hinted case, but
does it
> (or cairo's code?) actually do best there?

Sometimes it does. This is obvious looking through Sylvain’s page.
Ignoring that this is the old BCI-vs-Autohinter taste issue (de
gustibus, etc), it’s a lot more contingent on the particular font and
size whether it /is/ best.

> I'm wondering if we shouldn't automatically choose a filter based on
the
> HINT_STYLE option. I'm also wondering that if we do decide to expose
these in
> the API whether we should just export two options absed on their
general
> characteristics, (INTER_PIXEL and INTRA_PIXEL ?), rather than so much
about
> their details implementation, (FIR3 and FIR5, etc.).

Well, these are only aliases, the actual names are DEFAULT, LIGHT and
LEGACY (or vice versa?). I’ve been using the name FIR5 because DEFAULT
would be confusing since at the moment LEGACY is the default and not
DEFAULT (sic!). I don’t think any one of them should be removed.

--Tobias

¹ http://bugs.freedesktop.org/show_bug.cgi?id=10301
² http://www.alice-dsl.net/towolf/cairo/


> Well, this is all a little bit off-topic for the specific bug here,
and it's
> getting into API discussion that really needs to take place on the
cairo list.
> 
> Let's move the discussion there. Feel free to quote my stuff liberally
or
> completely if you'd like to reply on the list.
> 
> Thanks,
> 
> -Carl
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20081011/7785d961/attachment.html