Hi Behdad,<div><br></div><div>Haha! Good thing. I've already started working on it. And that's about the way I've set it up.</div><div>One question I have is whether I'll need to handle ARGB32 surfaces, as the current code simply handles 3x (width/height) CAIRO_FORMAT_A8 surfaces. Should I just assume we'll only need it for the A8 case and assert so in the function? Expanding the code to filter ARGB32 surfaces would be ... tricky.</div> <div><br></div><div>Lance<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 10:35 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> The filtering should go into a file of its own for now.  "cairo-lcd-filter.c"<br> works for me.  The public API will look like what was committed and reverted.<br>  The main function in that file will take a cairo image surface and a<br> filtering mode and subpixel order, and returns a new surface that has the<br> filtering results...<br> <br> The rest of the work will be done in cairo-scaled-font.c.  Note that I need to<br> do some code reshuffling before this can be hooked up.<br> <br> Thanks,<br> <font color="#888888">behdad<br> </font><div><div></div><div class="Wj3C7c"><br> Lance Hepler wrote:<br> > Hi Owen,<br> ><br> > It seems that Behdad is not interested in disturbing the ability to do<br> > native-style rendering. He's interested in making it possible to do<br> > rasterization in cairo so that animation of text can be done well. This<br> > is an excellent point.<br> ><br> > I don't see any issues in that at all. The question is, how/where do I<br> > want to put a new file/funtions that contains the lcd filtering code<br> > that I've ripped from freetype? And how do we want this API to look,<br> > even if we keep it private for cairo until we're happy with it?<br> ><br> > I'm perfectly fine ripping out the sections of freetype that do the<br> > filtering (I'm sorry D. Turner!), making another file (seems best, since<br> > we want this filtering available for all backends, not just freetype)<br> > for doing lcd filtering in the cairo src directory, and hooking the<br> > calls in cairo-ft-font.c to use this code to filter instead of Freetype.<br> > Looking over ftlcdfil.c it doesn't seem to be too difficult to adjust<br> > the code to work within a cairo-only context. As long as we keep pulling<br> > in the preferences from fontconfig, there shouldn't be any regressions,<br> > and I don't foresee tremendous difficulty in making this adjustment. Of<br> > course, I haven't looked at the formats we're using to keep the other<br> > backends bitmapped glyphs, so maybe I'm just naive.<br> ><br> > Anyways, doing this now will give us the immediate benefit of having<br> > these improved filtering methods finally upstream, which would be of<br> > benefit to the unnamed distros that are currently using one version of<br> > the 10301 patch or another. That, and I'm sure users of those distros<br> > that are not using the 10301 patches will benefit from/be grateful for<br> > the improved font rendering. Really, I just want to go the route that<br> > will upstream these filtering abilities as soon as possible.<br> ><br> > I am really interested and anxious to see the putative improvements in<br> > font rendering Behdad has planned (subpixel positioning for<br> > unhinted/slightly-hinted fonts might be really nice! (they aren't really<br> > affected by the lsb/rsb deltas)).<br> ><br> > Nicolaus (Lance)<br> ><br> > On Thu, Jan 29, 2009 at 11:48 AM, Owen Taylor <<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a><br> </div></div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>>> wrote:<br> ><br> >     On Thu, 2009-01-29 at 01:39 -0500, Behdad Esfahbod wrote:<br> >     > Hi Lance,<br> >     ><br> >     > I agree with most of your positions.  However, my long term plan<br> >     is to move<br> >     > glyph rasterization away from FreeType and into cairo, and that<br> >     includes<br> >     > subpixel rendering.  I think the API should wait till that<br> >     happens.  In that<br> >     > case Carl's remaining issues will be moot as we can do the same<br> >     filtering on<br> >     > all platforms and it will not be FreeType-specific anymore.<br> ><br> >     One thing to be concerned about is that matching the system rendering.<br> >     Whether text looks good is not just a matter of whether it looks good in<br> >     isolation, but whether it matches other text on the screen in contrast<br> >     and other characteristics.<br> ><br> >     For example, if you take some text rendered on the Mac, and drop it onto<br> >     a Windows desktop, the typical reaction will be that it is fuzzy. Taking<br> >     text the other way may produce complaints about letter shapes or color<br> >     fringing.<br> ><br> >     - Owen<br> ><br> ><br> ><br> </div></div></blockquote></div><br></div>