> If you read the OT-SVG table spec, multiple glyphs can refer to the
> same SVG document. Then for a glyph eg. 1234, client is expected to
> render the element with id "glyph1234" in the referenced SVG
> document.
OK, thanks. Since my SVG knowledge is virtually zero, the following
question might be silly: Do you think that this kind of `caching'
should be done on the FreeType side or on the SVG side?
That's interesting question. Ideally font is memory-mapped and FreeType just returns a pointer to the SVG document, so there's no copying involved. Then the client can do any caching if they deem necessary. But given the way FreeType works, that might not be possible. I suggest returning a copy of the string as FreeType probably have to, but possibly expose API that shows which glyph ranges share the same document.
In HarfBuzz, we have a type hb_blob_t to encapsulate chunk of bytes and do the memory-ownership management on it. So we just return a hb_blob_t per glyph, and client can, if it chooses to, peek at the pointer to the data the blob points to to do the caching. So, HarfBuzz SVG API is really just:
HB_EXTERN hb_bool_t
hb_ot_color_has_svg (hb_face_t *face);
HB_EXTERN hb_blob_t *
hb_ot_color_glyph_reference_svg (hb_face_t *face, hb_codepoint_t glyph);
|
I think something as simple as that is a good start. Realistically, not many fonts combine multiple glyphs into the same SVG documents, for obvious reasons of workflow: fonts are built out of a collection of standalone SVGs much more often than hand-curated SVG documents representing multiple glyphs each.