Here's a patch for something that has caused me some trouble. tt_face_init
in ttobjs.c uses logical OR to concatenate a series of calls to functions
that return integer error codes. Unfortunately, logical OR converts the
error code, if any, to 1, because it returns a boolean value, 0 or 1.
That had the very irritating consequence for me of changing
FT_Err_Out_Of_Memory (0x40) into FT_Err_Cannot_Open_Resource (0x01) which
sent me on a wild goose chase.
Before anybody points it out, yes, I know that this may all be my fault
(because I modified this code some time ago) but I suspect I just adapted a
technique that was already used. But I apologise if I did perpetrate this
howler.
Here's a diff (from Perforce - I hope the format is okay):
229d228
<
233,236c232,236
< error = tt_face_load_cvt( face, stream ) ||
< tt_face_load_fpgm( face, stream ) ||
< tt_face_load_prep( face, stream );
<
---
> error = tt_face_load_cvt( face, stream );
> if ( !error )
> error = tt_face_load_fpgm( face, stream );
> if ( !error )
> error = tt_face_load_prep( face, stream );
238c238,242
<
---
> error = tt_face_load_loca( face, stream );
> if ( !error )
> error = tt_face_load_cvt( face, stream );
> if ( !error )
> error = tt_face_load_fpgm( face, stream );
240,244c244
< error = tt_face_load_loca( face, stream ) ||
< tt_face_load_cvt( face, stream ) ||
< tt_face_load_fpgm( face, stream ) ||
< tt_face_load_prep( face, stream );
<
---
> error = tt_face_load_prep( face, stream );
In any case, the new code looks like this:
#ifdef FT_CONFIG_OPTION_INCREMENTAL
if ( !face->root.internal->incremental_interface )
error = tt_face_load_loca( face, stream );
if ( !error )
error = tt_face_load_cvt( face, stream );
if ( !error )
error = tt_face_load_fpgm( face, stream );
if ( !error )
error = tt_face_load_prep( face, stream );
#else
error = tt_face_load_loca( face, stream );
if ( !error )
error = tt_face_load_cvt( face, stream );
if ( !error )
error = tt_face_load_fpgm( face, stream );
if ( !error )
error = tt_face_load_prep( face, stream );
#endif
Best regards,
Graham Asher
_______________________________________________
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
