>> I don't think so – at least, I hope that this won't happen.
>> Ideally, the OpenType specifications gets updated to use the
>> forthcoming W3C standard as soon it is finished.
>
> Given that we make SVG renderers "pluggable", even if this does
> happen, won't we be able to just resort to some better library that
> will have those features (which are not supported by SVG Native)?
> As far as I think, even if some fonts use features which are not
> directly a part of SVG Native, as long as the renderers are
> pluggable, we shouldn't be having much trouble. Is my understanding
> correct?
You are correct. What I want are actually three tasks.
(1) Provide one or more API functions in FreeType that set up hooks
(i.e., function pointers) for calling SVG routines. What hooks
are necessary is something to be evaluated. For example, it could
be necessary to have hooks for
global SVG initialization (called once per creation of an
`FT_Library' or `FT_Face' object)
local SVG initialization (called once per creation of a glyph
slot)
execution of the glyph's SVG code (as taken from the font's
`SVG' table)
local SVG clean-up
global SVG clean-up
This is an educated guess only, since I have zero knowledge how
SVG libraries actually work.
(2) Adjust FreeType's build system to select a default SVG library
(including rendering support) in case the user doesn't override
it. Again, it is still something to evaluate which library should
be the default, but `svgnative' looks like a good candidate.
BTW, the test for rendering support must be part of the SVG
library, not FreeType. Ideally, the SVG library provides a
function that returns its built-in (or run-time) capabilities.
(3) Write a wrapper (i.e., a few lines of C code) for the default SVG
library so that (2) works out of the box.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
