FT_Outline objects seem to have some tricky aspects to them: they have “n_contours” and “n_points” fields to indicate the _used_ sizes of the “points”, “tags” and “contours” arrays, but no explicit way of indicating the actual _allocated_ sizes of these arrays. It looks like the caller has to keep track of that.
For example, FT_Stroker_Export and FT_Stroker_ExportBorder blithely assume they can append data onto these arrays, and increment n_contours and n_points accordingly. So a basic technique for calling these would be to call FT_Stroker_GetCounts or FT_Stroker_GetBorderCounts to find out how much space the export will use, call FT_Outline_New to allocate a new FT_Outline with sufficient space, then _set its n_contours and n_points to zero_ before passing it to the export routine to fill it in. In Python, I wanted to avoid all this messing about. So I implemented an “append” method for my Outline wrapper class, which allocates a new FT_Outline, big enough to hold both the existing and the additional sets of outline data, copies all the data into it, and replaces the Outline’s internal FT_Outline object with the new one. To go with this, my Outline class implements a “new” method which creates a new Outline with room for 0 contours and 0 curve points. And in my Stroker class, the export methods do an append to the Outline you pass to them, so you never have to worry about overrunning the arrays. _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
