Re: [ft-devel] SVG "Native" Re: [ft] Three GSoC projects for FreeType

[Werner LEMBERG]

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