> 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.
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
