[Top][All Lists]
[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
- [ft-devel] inconsistently dropping sub-pixel features, Ken Sharp, 2010/03/17
- Re: [ft-devel] inconsistently dropping sub-pixel features, James Cloos, 2010/03/18
- Re: [ft-devel] inconsistently dropping sub-pixel features, Ken Sharp, 2010/03/18
- Re: [ft-devel] inconsistently dropping sub-pixel features,
Ken Sharp <=
- Re: [ft-devel] inconsistently dropping sub-pixel features, Werner LEMBERG, 2010/03/20
- Re: [ft-devel] inconsistently dropping sub-pixel features, Ken Sharp, 2010/03/20
- Re: [ft-devel] inconsistently dropping sub-pixel features, Werner LEMBERG, 2010/03/20
- Re: [ft-devel] inconsistently dropping sub-pixel features, Ken Sharp, 2010/03/21
- Re: [ft-devel] inconsistently dropping sub-pixel features, Werner LEMBERG, 2010/03/21
- Re: [ft-devel] inconsistently dropping sub-pixel features, Ken Sharp, 2010/03/22
Re: [ft-devel] inconsistently dropping sub-pixel features, Werner LEMBERG, 2010/03/19