As you would already know, we need an SVG rendering library that we can set as the default one for FreeType. Over the next few days and especially this weekend, I'll be trying to audit the major available SVG rendering libraries (that I know about so far) and comparing them on the basis of some criterion.
Some that I have on top of my head are:
There are also options like `QtSvg' but they seem quite unlikely. Still not off the table for now.
If you have any more to recommend, please let me know. It'd be great if while making the recommendation, you take Toshiya's points into account and possibly comment about them. I am quoting them here for reference:
* where we can reach the latest source code under development?
* how about the SVG features covered by the software?
* the part of SVG rendering is well separated, packaged and distributed?
* the APIs of SVG rendering are well stabilized?
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.
2. Dependency Tree: As previously discussed, we will be declaring the library an external dependency just like `libpng' currently is. But still, I guess we would consider the dependencies of the library. We don't want the users of FreeType to have to install a lot of stuff just to get FreeType running with SVG glyph support. Not only the sizes of these dependencies, but also how likely they are to be already installed on major systems.
3. How much work to do make it work with FreeType: Does it need a C API wrapper? If the core of the library is written in some other language will there be a problem due to that on major platforms? 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. Toshiya, please correct me if I am wrong here.
4. Maturity and Maintenance: All I mean by that is, how probable it would be for some major bug to pop up? Are there popular projects relying on the library? If bugs and issues do get identified, how fast are they fixed? How active are the developers?
5. Testing: Is the library well tested? Is there a need for aggressively testing SVG glyph renderings from our side?
6. Stability: How stable are the APIs. We don't want something that changes its interface fast and breaks our code.
7. SVG Rendering part being well separated, packaged and distributed: As far as I think, there can be some options which are not SVG rendering libraries themselves but might have it in some part of their codebase. In that case, we would like to consider whether that part can be separated, packaged and distributed. Toshiya, if I have got it wrong, please correct.
Point 6 and 7 are crucial and I didn't have them in my mind. Thank you Toshiya for highlighting these.
Note that this is in no means a comprehensive list, please add anything that you think might be crucial.
Werner and Toshiya, please correct me if I have got any idea wrong here.
Regards,
Moazin