[ft] python_freetype Design: Outline Objects

[Lawrence D'Oliveiro]

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.