Re: [ft] OTF rendered strangely at large sizes (mono)

[Alex Taylor]

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 <address@hidden>
http://www.altsan.org