freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] inconsistently dropping sub-pixel features


From: Ken Sharp
Subject: Re: [ft-devel] inconsistently dropping sub-pixel features
Date: Fri, 19 Mar 2010 11:09:36 +0000

Hi James, all,

At 10:49 18/03/2010 -0400, James Cloos wrote:

It looks like ftraster.c:Vertical_Sweep_Drop() is responsible for that.

Actually this routine never gets called in either case. It seems the vertical pass processing decides there is nothing to do. That is, in Render_Single_Pass for the vertical pass, fProfile ends up as NULL, so we don't call Draw_Sweep.


I wonder whether the Overshoot_Top and Overshoot_Bottom flags remain
constatnt when the glyph is flipped with FT_Set_Transform()?

The flags do seem to be reversed, the 'working' case gets Overshoot_Top while the flipped, nonworking, case gets Overshoot_Bottom. This appears to be due to the fact that the glyph vertical direction is reversed, because the outline has been flipped. So instead of flowing up (in the working case) the glyph is marked as flowing down.


It seems that in the 'working' case, ie where the glyph does not disappear, the pixels are marked by the *horizontal* drop out control code.

The reason that the dropout correction doesn't get applied to the 'incorrect' case is because in ftraster.c:Horizontal_Sweep_Drop, line 2608:

    e1 = TRUNC( pxl );

    if ( e1 >= 0 && e1 < ras.target.rows )

pxl is -4096 and e1 drops to -1, so we don't mark the pixel in the raster.

pxl is set from either e1 or e2, which according to the comment are the centres of the pixels. I think these are not expected to both be below 0....


I'm not certain why this is happening of course, I don't understand the code well enough yet. I believe it is something to do with offsetting the outline by half a pixel. This results in the lowest bound of the outline becoming -2048 (-half a pixel) while the upper bound becomes -448 (-7 64ths of a pixel).

Because we have offset the outline like this, it lies entirely outside the current pixel. The flipped glyph works because after offset by half a pixel it still has an upper bound inside the current pixel, and so it gets set.



                    Ken





reply via email to

[Prev in Thread] Current Thread [Next in Thread]