Re: [Devel] BCI no longer used by default

[Antoine Leca]

Werner LEMBERG écrivit:

>> - ftview-2.1.9-no-autohint.png: compiled with freetype 2.1.9
>> with bytecode interpreter enabled and unpatented hinting algorithm
>> removed (commented out #define TT_CONFIG_OPTION_UNPATENTED_HINTING)
>
>> Some examples of differences:
>> - The '3' in 13: ... is less perfect in 2.1.9;
>
> This is exactly how the glyph is hinted, as can be seen in the
> fontforge snapshot after applying all instructions.  The green lines
> should actually be splines, but it is not difficult to imagine which
> pixels centers are actually within the outline.
>
>> - The small 'e's up to size 15 are much worse in 2.1.9;

I have examined more closely 'e' at 15 ppem. The glyf program is very
simple, and I do not understand why it produces such a figure. Particularly
have a look at points 12 (bottom) and 18 (top).

The relevant part of the program is as follow:
 00048: SVTCA[y-axis]
 00049: SRP0       , 28
 00050: MIRP[nrp0,nmd,rd,0], 12 ,  140
 00051: MIRP[srp0,nmd,rd,0], 18 ,  184

In not-so-cryptic English:
 - begin hinting y-axis
 - take base as point 28 (it is the origin)
 - move point 12 according to CVT 140 (this will effectively force the
overshoot to be 0)
 - move point 18 according to CVT 184 (this will effectively set the top
position) and set further reference to this point

If we take a look at Werner's fontforge snapshot (vera-15-e-debug.png), we
see that points 28 and 12 are aligned (so the move was done accordingly; the
original scaled distance was 0.21 pixel) but are slightly below the
baseline, about 0.45 pixel (this is NOT what I would expect). This is
particularly surprising for point 28 that is loaded at 0,0 at any rate.

In fact, even if it is difficult to compare both drawings (with splines in
the Windows snapshot I sent earlier and the raw lines between the online
points of fontforge), I consider the general shape are correct, with the
exception of a general offset toward bottom of about 0.45 pixel.

I hope I have given sufficient paths to force the bugs (a watchpoint on the
y coordinate of point 28 might do the job). My idea at this point is that
the loader, for whatever reason, initialise the Y value of the origin point
(the first that is _not_ stored in the font). I am sorry I cannot help more,
my setup right now does not allow me to do actual debugging of Freetype.


Antoine