<div dir="ltr">If you absolutely want to support LCD filtering even if FreeType doesn't, then I really<br>recommend you to simply ignore the FreeType-specific APIs and just re-implement the<br>damn thing in Cairo.<br><br> then deal with the legal consequences yourselves...<br><br><div class="gmail_quote">2008/9/28 Sylvain Pasche <span dir="ltr"><<a href="mailto:sylvain.pasche@gmail.com">sylvain.pasche@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">Carl Worth wrote:<br> > On Sat, 2008-09-27 at 18:22 +0200, Sylvain Pasche wrote:<br> >> The test assumed that FreeType was compiled with that option. Ideally,<br> >> it should have used two reference images, and switch the image to test<br> >> according to the HAVE_FT_LIBRARY_SETLCDFILTER macro value. I'm not sure<br> >> this is possible to do with the current test infrastructure.<br> ><br> > A macro is a compile-time option. But the capabilities of the freetype<br> > libraryy can be varied at runtime. So that's not an interesting place to<br> > start at all.<br> <br> </div>That's right. A better alternative could be to include<br> FT_CONFIG_OPTIONS_H and check for FT_CONFIG_OPTION_SUBPIXEL_RENDERING.<br> The macro should match the option that was used when FreeType was<br> compiled. The constraint will be that configure and the test should be<br> compiled and run against the same FreeType.<br> <font color="#888888"><br> <br> Sylvain<br> </font><div><div></div><div class="Wj3C7c"><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> </div></div></blockquote></div><br></div>