Re: [ft] Strange hinting of cff font

[David Turner]

Hello Boris,

it's definitely a bug in the Postscript hinter. To be fair, I never really
tested its accuracy with ghost stems, and it shows :-)

the problem is that the code you've shown in your previous mail should only
be used to "strengthen" small non-ghost stems. Its purpose is to transform
any "small" stem to a 1 pixel-width, aligned to the pixel grid.

in this context, the computation "pos = FT_FLOOR(pos + (len >> 1))" is correct
because:

  * pos is the left/bottom edge, the right/top one being at (top+len)

  * the stem's center is stem_center = pos + (len >> 1)

  * we want to find the nearest pixel center, for ONE=64, this is:

       nearest_center = FT_ROUND(stem_center - ONE/2) + ONE/2

  * the corresponding left and right edges are at:

       left  = nearest_center - ONE/2 = FT_ROUND(stem_center - ONE/2)
       right = left + ONE

  * but FT_ROUND(x) = FT_FLOOR(x+ONE/2), so:

       left = FT_FLOOR(stem_center)
       len  = right-left = ONE

The problem is that this computation shouldn't be applied to ghost stems,
whose "length" is 0, it's is simply better to round the position directly
in this case.

I suppose that your fix works because there are no other "small" stems in
your font, but this cannot be generalized.

Similarly, for really tiny stems, the automatic strengthening is probably
a bad idea. It's certainly worthy for lengths between ONE/2 and ONE, for
smaller one, we should probably leave the stem as is, or simply move its
center to the nearest pixel center, without changing its length...

I have just commited a fix to the CVS that does just that. Could you please
test it with more CFF fonts ?

Thanks,

- David



On Tue, 20 Feb 2007 16:06:56 +0100, "Boris Letocha" <address@hidden> said:
> Hi,
> 
>  
> 
> We have found strange hinting in attached a.cff font - some characters
> (eg. "lmn") are shown 1 pixel under baseline (see in attachment) in 300
> DPI and 10 pt size, without antialiazing, if you use autohinter or
> without hinter it looks ok.
> 
>  
> 
> Now please be kind to me in next lines, I really don't understand
> hinting stuff enough.
> 
> If you look for example at "n" character it start with hstems (17,-4)
> -21 and (471, 451) -20.
> 
>  
> 
> Hstems are processed in this code from pshrec.c:
> 
>   /* add a new single stem (called from "T1Stem" method) */
> 
>   static FT_Error
> 
>   ps_dimension_add_t1stem( PS_Dimension  dim,
> 
>                            FT_Int        pos,
> 
>                            FT_Int        len,
> 
>                            FT_Memory     memory,
> 
>                            FT_Int       *aindex )
> 
>   {
> 
>     FT_Error  error = 0;
> 
>     FT_UInt   flags = 0;
> 
>  
> 
>  
> 
>     /* detect ghost stem */
> 
>     if ( len < 0 )
> 
>     {
> 
>       flags |= PS_HINT_FLAG_GHOST;
> 
>       if ( len == -21 )
> 
>       {
> 
>         flags |= PS_HINT_FLAG_BOTTOM;
> 
>         pos   += len;
> 
>       }
> 
>       len = 0;
> 
>     }
> 
>  
> 
> This looks correctly by specification - it contains these 2 "ghost"
> hstems on positions -4 and 471.
> 
>  
> 
> Problem probably is that number -4 is scaled to -10 then floored to -64
> (-1 pixel) in this code in pshalgo.c (pos=-10 and len=0):
> 
>           /* Stem adjustment tries to snap stem widths to standard
> 
>            * ones.  This is important to prevent unpleasant rounding
> 
>            * artefacts.
> 
>            */
> 
>           if ( glyph->do_stem_adjust )
> 
>           {
> 
>             if ( len <= 64 )
> 
>             {
> 
>               /* the stem is less than one pixel; we will center it
> 
>                * around the nearest pixel center
> 
>                */
> 
> #if 1
> 
>               pos = FT_PIX_FLOOR( pos + ( len >> 1 ) );
> 
> #else
> 
>              /* this seems to be a bug! */
> 
>               pos = pos + FT_PIX_FLOOR( len >> 1 );
> 
> #endif
> 
>               len = 64;
> 
>             }
> 
>             else
> 
>             {
> 
>               len = psh_dimension_quantize_len( dim, len, 0 );
> 
>             }
> 
>           }
> 
>  
> 
> This #if 1 already looks suspicious, so we just tried to change it from
> FT_PIX_FLOOR to FT_PIX_ROUND:
> 
> #if 1
> 
>               pos = FT_PIX_ROUND( pos + ( len >> 1 ) );
> 
> #else
> 
>  
> 
> And after this change it also looks correctly. Also comment before talks
> about "center it around the nearest pixel center" - floor is not nearest
> from my understanding, but I really don't understand this code enough.
> 
>  
> 
> Now main question it is wrong font or bug in FreeType. Do you know any
> other product other then FreeType to test this font in same conditions?
> 
>  
> 
> Thanks,
> 
>  
> 
> Boris Letocha
> 
>  
>