> 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.
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
