Re: [ft-devel] The criterion for comparing SVG Rendering libraries

[Werner LEMBERG]

>> 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