On Mon, 02 Sep 2013 20:24:30 +0200 (CEST) Werner LEMBERG wrote: > > This shows Brill (a high-quality free-for-non-commercial-use OTF) > > rendered through my driver at various sizes. Notice how, at 144pt, > > all curves look 'squared-off' -- compare especially the letter 'e' > > at 144pt versus the other sizes. > > [144pt at which resolution? It's neither 72 nor 96dpi...]
It's actually at 120dpi, sorry. (Well, to be more accurate, that's what requested by the OS - the driver translates that internally to the equivalent size at 72dpi for rendering, which I guess would be 240pt.) > I have absolutely no explanation how you get these results, and I > can't repeat it on my GNU/Linux box. My bad. I think I've figured out what's happening, and it is indeed my fault. With some tracing I figured out that the OS graphics engine actually ISN'T requesting a bitmap for characters at that size - there must be a cutoff somewhere at which point it requests an outline instead, which it assumes responsibility for rasterizing itself. So it's requesting an outline, which the driver converts into the format expected by the graphics engine. So the fault is very likely in the logic the driver uses to do that outline translation. I'm pretty sure I know what that is, actually. I rather unthinkingly retained the conversion logic intact from the old (FreeType v1-based) driver; but since that code was TrueType-specific, it evidently assumes all the splines are quadratic instead of cubic. The graphics engine expects cubic splines (in its own particular format)... this old code is therefore trying to convert the control points into third-order from second-order. When it encounters CFF outlines... I think you can see what goes wrong with that logic. :) The effect is admittedly rather interesting... Thanks. -- Alex Taylor <[email protected]> http://www.altsan.org _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
