RE: [ft-devel] Two patches for FT

[Turner, David]

> > Your screenshot shows that there's something fishy with FreeType's
> > TT code.  If you call `ftview -r 96 8 tahoma.ttf' (from the current
> > CVS, with bytecode interpreter and patented hinting enabled) you can
> > see that both the glyphs `6' and `8' have one pixel too much.
> > Either there's a bug in the bytecode interpreter, or there is a
> > problem with the dropout code in the renderer.
> 
> With the current CVS of fontforge (earlier versions won't work
> correctly) I've debugged the instructions of the `8' glyph.  It is a
> rounding problem, and it seems to be a very subtle one.  The last
> DELTAP1 instruction in the hinting code moves point 17 0.375 units up
> (at 11 ppem).  This causes a shape change as shown in the attached
> images.  As can be seen, the spline almost hits the pixel center which
> decides whether the pixel is on or off.  Within Windows, the pixel
> center is *below* the curve, so it is off.  Within FreeType, the pixel
> center is *above* (or on) the curve, so it is on.  David?
> 
If I understand correctly what you're saying, the rendering difference
would come from the way Windows and FreeType tesselate the bezier arc.

Could someone give me the coordinates of the three control points. It
should be easy to check wether the pixel center should be below or
above the curve with some computational tricks. The graphics seems to
show that the arc should be below the pixel center, but I hope it's
wrong.

I sincerely hope that this is caused by a bug in our tesselation
algorithm, instead of Windows's one. Otherwise, we're going to have
a hard time re-implementing the "feature".

Another possibility would be that the point position before the DELTAP1
isn't correct, which would represent a different challenge to debug.

- David Turner
- The FreeType Project  (www.freetype.org)


> 
>     Werner
>