Hi Owen,<div><br></div><div>It seems that Behdad is not interested in disturbing the ability to do native-style rendering. He's interested in making it possible to do rasterization in cairo so that animation of text can be done well. This is an excellent point.</div>
<div><br></div><div>I don't see any issues in that at all. The question is, how/where do I want to put a new file/funtions that contains the lcd filtering code that I've ripped from freetype? And how do we want this API to look, even if we keep it private for cairo until we're happy with it?</div>
<div><br></div><div>I'm perfectly fine ripping out the sections of freetype that do the filtering (I'm sorry D. Turner!), making another file (seems best, since we want this filtering available for all backends, not just freetype) for doing lcd filtering in the cairo src directory, and hooking the calls in cairo-ft-font.c to use this code to filter instead of Freetype. Looking over ftlcdfil.c it doesn't seem to be too difficult to adjust the code to work within a cairo-only context. As long as we keep pulling in the preferences from fontconfig, there shouldn't be any regressions, and I don't foresee tremendous difficulty in making this adjustment. Of course, I haven't looked at the formats we're using to keep the other backends bitmapped glyphs, so maybe I'm just naive.</div>
<div><br></div><div>Anyways, doing this now will give us the immediate benefit of having these improved filtering methods finally upstream, which would be of benefit to the unnamed distros that are currently using one version of the 10301 patch or another. That, and I'm sure users of those distros that are not using the 10301 patches will benefit from/be grateful for the improved font rendering. Really, I just want to go the route that will upstream these filtering abilities as soon as possible. </div>
<div><br></div><div>I am really interested and anxious to see the putative improvements in font rendering Behdad has planned (subpixel positioning for unhinted/slightly-hinted fonts might be really nice! (they aren't really affected by the lsb/rsb deltas)).</div>
<div><br></div><div>Nicolaus (Lance)</div><div><br><div class="gmail_quote">On Thu, Jan 29, 2009 at 11:48 AM, Owen Taylor <span dir="ltr"><<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">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 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>
</div>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>
<font color="#888888"><br>
- Owen<br>
<br>
<br>
</font></blockquote></div><br></div>