Essentially you can pack a lot of information into the currently
unused (FT_GlyphSlot)->other. I was simply coloring each outline
contour with a monocolor using that pointer as a reference to the
array of colors. I would imagine that it can refer to bi-color
gradient or SVG document(s), especially if the glyph is tagged with
FT_GLYPH_FORMAT_SVG. There is also (FT_GlyphSlot)->subglyphs that you
can appropriate accordingly.
To be honest, I have been thinking about this from day one. But always slid it
off the table thinking that, no this is a hackish way of doing it since the fields
aren't actually there for SVG data, they exist for other reasons and are supposed
to be used for that. Now I realize I was wrong.
Keep us posted but try to use public fields if at all possible:
(FT_GlyphSlot)->other, (FT_GlyphSlot)->subglyphs, and perhaps
(FT_GlyphSlot)->control_data.
I have tried using `other' field. Works perfectly! :) I am going to start working on
the glyph management API and see how it goes.
Just one question, I grepped the source code of the current master to see where
else `other' field was being used. It turns out that it is used only once inside the
function `cff_compute_max_advance' which is currently not in use with the
comment, "unused until we support pure CFF fonts". Can you help me understand
what a pure CFF fonts is? I want to make sure nothing conflicts since I will be using
`other' field for SVG data.