<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.24.0"> </HEAD> <BODY> Salvete, my first post. This is a follow-up to Carl’s comment on bug <A HREF="http://bugs.freedesktop.org/show_bug.cgi?id=10301">http://bugs.freedesktop.org/show_bug.cgi?id=10301</A> 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: <A HREF="http://spasche.net/files/lcdfiltering">http://spasche.net/files/lcdfiltering</A> . 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: <A HREF="http://article.gmane.org/gmane.comp.lib.cairo/9347">http://article.gmane.org/gmane.comp.lib.cairo/9347</A> > 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 ¹ <A HREF="http://bugs.freedesktop.org/show_bug.cgi?id=10301">http://bugs.freedesktop.org/show_bug.cgi?id=10301</A> ² <A HREF="http://www.alice-dsl.net/towolf/cairo/">http://www.alice-dsl.net/towolf/cairo/</A> > 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 > </BODY> </HTML>