smoke@well.sf.ca.us (Nicholas Jackiw) (06/25/91)
This might be too much to ask for, but does anyone have any sharable
code for accessing the spline control points describing a True-Type
glyph? Ideally (and with whatever amount of preprocessing it takes),
I'd like to read in an sfnt, preprocess, and then be able to code
along these lines:
for each contour in the glyph,
for each point on the contour,
determine X, Y, and whether-on-curve for that point
I'm using v1.0 of the TrueType spec, and have no problem going from
a character through the cmap to a glyph index, and then from the loca
(by way of the head) to the glyf data table, but at that point I'm
stumped. Parsing the actual glyf table seems a more dread task than
hand-assembling ictb resources in hex!
If anyone's done this, even if they can't share code, I'd love to hear
from them...and promise to post code I write for anyone's use. Am I
correct in assuming that
endPtsOfContours[numberOfContours]
gives me the total number of points whose coordinates are stored in
xCoords[] and yCoords[] (even though these are compacted)? And then
is it merely a task of starting at flags[0] (which is located at
@instructions+instructionLength??), walking through the compressed
flag array until I've counted total-number-of-points (expanded) flags
to locate the beginning of XCoords[], then walking through XCoords[]
in conjunction with a rewalk of flags[] (because flags[] contains
data about XCoords[] compaction) to find the start of YCoords[], and
then rewalking all three arrays in tandem to finally get each control
point's X, Y, and on-curve values?
Surely TrueType must itself occasionally need the coordinates of some
point. Even if it unpacks this table once and then makes all of its
accesses to a nice, decompressed format, does it really need to
step through the flags array three times before even locating the
base address of the y-coordinate data?
I am surely confused. Can anyone help? Thanks!