Keith Packard wrote: > Perhaps, but I would hope most users can use the bytecode interpreter, > which means that the current filter would be a better default. Throwing > away the carefully constructed outlines produced by the bytecode > interpreter is a huge waste. As I'm sure you know, many users might not be legally allowed to use the bytecode interpreter... Don't tell Apple, but I did some tests with bytecode-enabled Freetype, on some of Microsoft's TrueType fonts, to see what kind of differences we're talking about: <http://www.kaseorg.com/~anders/subpixel-before-bytecode.png> <http://www.kaseorg.com/~anders/subpixel-after-bytecode.png> I still think my filter is an improvement, but even if you consider this to be a worst case--do you really think I'm "throwing away the outlines," and the difference really great enough to warrant defaulting to a filter that produces output nearly equivalent to grayscale for heavily hinted text, and bad color artifacts in all other cases? If you still think so, fine, but I hope that I've at least convinced you that making the filter configurable is worthwhile. Should I try to do that? > Yes, so we'd have to adjust the bounding box to cover the expanded pixels > touched by the filtered output. Oh, I thought I already am, by adjusting left/right (or bottom/top, for vertical subpixels), which get propogated to the metrics. Am I missing something? > This may be a problem for terminal > emulators which assume that glyphs don't ever overlap, and other > applications which assume that adjacent lines of text don't overlap. Monospace fonts get clipped to a box anyway by the current code. I've had no problems except that GTK underline bug, which is hardly noticable and could be fixed in GTK by using the offsets instead of the bounding box (again, Mozilla gets it right). I even tested with a pathologically wide 5 pixel blurring filter in all four subpixel layouts (okay, maybe that constitutes throwing away the outlines :-)). Anders
