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