Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

[Hin-Tak Leung]

--------------------------------------------
On Sat, 2/7/16, Werner LEMBERG <address@hidden> wrote:
 
 > I
 have started testing the new implementation of rasterization
 tests
 > in font validator (background,
 planned in
 > https://github.com/HinTak/Font-Validator/issues/5
 ) and comparing
 > how the new test
 behaves, with the old 2003 binary.
 >
 > [...] seems to be doing the equivalent of
 :
 >
 > ...
 >           new_dist =
 org_dist;
 >         }
 >       }
 >       else
 >         new_dist = 0;
 >
 >   
    if( (new_dist == org_dist) &&
 OTHER_YET_UNKNOWN_CONDITION)
 >     
    EMIT_ERROR_MESSAGE();
 >
 ...
 >
 > I.e. the older
 2003 binary flags all the cases that Freetype
 > identifies as errors, but also more. Can
 you make a guess of what
 > those
 OTHER_YET_UNKNOWN_CONDITION might be?
 
 Sorry, I can't.  Do you have examples of
 failing fonts?
 
 Maybe Greg
 Hitchcock can help by looking into the MS rasterizer
 source
 code.
 
 

I do have a collection of which fonts and which glyphs it does not like on win 
8.1. Anyway, it seems to be doing

if ( (new_dist - cur_dist) != 0 && (new_dist - org_dist) == 0)
    EMIT_ERROR_MESSAGE();

i.e. it emits a error message whenever there is instruction to move a point but 
does not result in actual movement. I think that's a bit gratuitious - it 
basically tells the font designer that 'you have redundant instructions', which 
is not the same thing as 'you have invalid instructions' (where into supplied 
cannot determine a move).

besides 'RP1 and RP2 have the same position on the projection vector' above, I 
found the freetype code which silently works around 'Projection and freedom 
vectors at or near perpendicular' (the other popular errors from my list in 
https://github.com/HinTak/Font-Validator/issues/5 .) You work around it in 
Compute_Funcs ,
for much broader silent protection, but MS rasterizer seems to only warn on the 
narrower condition when the condition happens inside Direct_Move.

...
    /* at small sizes, F_dot_P can become too small, resulting   */
    /* in overflows and `spikes' in a number of glyphs like `w'. */

    if ( FT_ABS( exc->F_dot_P ) < 0x400L )
      exc->F_dot_P = 0x4000L;
...


That was in the initial freetype2 commit!

commit d2b1f357049f6b5e6766af9f3dfa134d2527feec
Author: David Turner <address@hidden>
Date:   Thu Dec 16 23:11:37 1999 +0000

    Initial revision


So the summary is that both errors are silently worked around in Freetype, and 
for years (in the 2nd case, from freetype 1 days, which is ~20 years ) ... and 
it would be good to tell font designers to fix them :-).


Hin-Tak