>> 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.
OK.
> In HarfBuzz, we have a type hb_blob_t to encapsulate chunk of bytes and do
> the memory-ownership management on it. [...]
>
> I think something as simple as that is a good start.
Thanks.
> 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.
Not having had a closer look at your SVG Emoji font, so I wonder
whether it contains such `hand-curated' stuff for testing purposes...
Otherwise, do you know test examples for that? Eventually, this
should all be added to a proper test suite.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
