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

[Werner LEMBERG]

> The criterion I have in mind is based on the following points:
>
> 1. *SVG Features*: This is very important.  Anything that doesn't
>    support all of the features of `SVG Native' specification would
>    probably not be considered.  The more features supported, the
>    better.

On the other hand, the SVG library should have easy means to reject
all stuff that is not part of `SVG Native'.

> 3. *How much work to do make it work with FreeType*: Does it need a
>    C API wrapper?

Yes.

>    If the core of the library is written in some other language will
>    there be a problem due to that on major platforms?

Actually, this is just a secondary condition.  FreeType only sees a
C header file and the already-compiled library.

>    Not only that, something like `svgnative' needs an improvement in
>    its build system to make sure it can be packaged and used on
>    major platforms with ease.

Basically, this is not our issue.  Of course, a library written in,
say, Haskell is not trivial to cope with since you need a completely
different, quite large infrastructure to compile it, but the end
result is the same: A C header file and an already-compiled library to
link with.

> 5. *Testing: *Is the library well tested?  Is there a need for
>    aggressively testing SVG glyph renderings from our side?

`Aggressively testing' on the FreeType side will be done with the
fuzzer, more or less.[*] On the other hand, it is always nice to have
an extensive test suite.

> 6. *Stability: *How stable are the APIs.  We don't want something
>    that changes its interface fast and breaks our code.

Hear, hear :-)


    Werner


[*] The fuzzer has the tendency to find issues in other libraries
    also.  For example, the current setup (for Chromium's ClusterFuzz
    incarnation) links with `libarchive', and I remember to have seen
    about 10 bugs related to it that the fuzzer reported over the last
    year.