-
Notifications
You must be signed in to change notification settings - Fork 2
Why EchoSVG
Some people ask about the motivations for a Batik fork, and reasons to use EchoSVG instead of Batik. This document is intended to answer those questions.
The code base of Apache Batik has not seen a significant change since 2016 when the Maven build landed. And bug reports (as well as Github pull requests, since they opened their Github mirror) are being ignored unless they are related to security. You are invited to browse their issue tracker to get an idea, almost no issues are being attended.
When the maintainer of this project attempted to use Batik as a dependency for a report-printing project, an easy to fix bug immediately prevented it. The problem was reported on JIRA but was never attended, like many others.
Since the EchoSVG fork was started, a number of bugs were fixed. See https://github.com/css4j/echosvg/releases/ for more details.
Other Batik problems prevented a correct modular use, see Script service provider metadata is at wrong module #20 which was only fixed by Batik 1.15 (released well after the fork was created), or BATIK-1289 and its solution #15.
EchoSVG is fully modularised.
Batik's test suite has reproducibility and usability issues, see From Batik test suite to EchoSVG tests.
Once it became clear that Batik was in a semi-zombie state and it could take forever to fix the issues, the EchoSVG fork was made. It was created to serve the needs of a specific project, but has proven useful to other people too.
If you still have questions about the fork or why to use EchoSVG instead of Batik, please check for an existing discussion about it, or open a new one.