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.

Status of Apache Batik

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.

Bugs

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.

Java modularity issues

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.

Broken test suite

Batik's test suite has reproducibility and usability issues, you are encouraged to read From Batik test suite to EchoSVG tests to see how this project has improved both the testing and the library itself.

The fork

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.

EchoSVG has improved Batik on many areas and, as an example of the improved reliability and specification compliance, this is a comparison of how an SVG file (filled with missing references) was rendered with EchoSVG, Firefox 117 and Inkscape 1.3 (Batik is not shown because it stops normal processing after the first error):

As you see, only this library renders the document as mandated by the SVG specification. Firefox misses the text, nor does it render the left middle square gradient fully correctly. Inkscape does a bit better with the gradient at the left square but also misses the text, as well as the colors of the top figures and the pattern in the right square.

Mermaid diagrams

According to EchoSVG users, the CSSTranscodingHelper is the only tool in any computer language, apart from the major browsers, that is able to render Mermaid diagrams, although not always flawlessly.

One example:

The EchoSVG test suite has well over a thousand tests, including a number of SVG images that Batik is unable to render.

New features

Apart from the bug fixes, the performance improvements and the aforementioned modular support, here is a summary of the new features in EchoSVG:

• CSS Selectors level 4.

• CSS Colors level 4 (and color-mix() from level 5).

• Supports the lh, rlh, rem, rex, vh, vw, vmin and vmax CSS length units (only EchoSVG 2.0 or via CSSTranscodingHelper).

• Other modern CSS (like custom properties or @supports rules) supported via CSSTranscodingHelper.

• Several steps towards SVG2, like the namespaceless href attribute.

• PNG codecs support ICC color profiles (applied automatically when the profile isn't built-in).

• Support for color profiles (even in rasterized embedded images) and new text attributes in the SVG Generator.

• Directly transcode SVG images that are embedded in HTML documents, even plain HTML ones.

• Configurable compression level for PNG images in PNGTranscoder and the SVG Generator.

• New rendering hints allow embedding textual information (like copyright, author, description, etc) in rendered PNG images.

• You can specify an encoding in TranscoderInput.

• DOM has matches(), querySelector() and querySelectorAll() from the modern DOM standard.

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.