[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft] python_freetype Design: Outline Objects

From: Lawrence D'Oliveiro
Subject: [ft] python_freetype Design: Outline Objects
Date: Fri, 13 Feb 2015 14:07:41 +1300

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]