Build size, options, documentation

[rschmunk]

The overall README describes some possibilities for different builds, with example gradle specifications. But not what I need, alas.

The problem I have is that the only option described that produces a jar that I immediately find useful is the "uber jar" or fat jar. And unfortunately it is 8 MB in size. By comparison the Batik "all" jar is about 4 MB.

My use case is that I would like a single jar that I can add to my product classpath, for a couple applications that users have said that they would like SVG output (in addition to the already provided PS or PDF). The Batik 4 MB jar seemed like bloat compared to my app sizes, but then I encountered Echo's uber jar.

So is there a way to produce a smaller Echo jar, rather than try to figure out which pieces and parts I need from the multiple-module build? It would be even better if as a Gradle build option I could specify "just give me the modules I need for writing an SVG file to disk, but in a single jar".

[carlosame]

The problem I have is that the only option described that produces a jar that I immediately find useful is the "uber jar" or fat jar. And unfortunately it is 8 MB in size. By comparison the Batik "all" jar is about 4 MB.

The uber jar is larger because it includes all the dependencies. You'll also need those dependencies if you use Batik, so the situation is similar.

EchoSVG, including the css4j engine and all its dependencies, is 4.52MB compressed. But you also need the org.w3c packages, the various Apache dependencies like xmlgraphics-commons, Mozilla Rhino for the Javascript, etc. Which sums 7.66MB.

A fat jar with Batik would be a bit smaller because the CSS engine is much simpler, but would be like 7.5MB anyway.

So is there a way to produce a smaller Echo jar, rather than try to figure out which pieces and parts I need from the multiple-module build? It would be even better if as a Gradle build option I could specify "just give me the modules I need for writing an SVG file to disk, but in a single jar".

Which build tool are you using? If you only need some echosvg module and its dependencies (from your description it isn't clear which module you need), your build tool should be able to do that. From a quick Google search:

1. Creating a Fat Jar in Gradle.
2. with Maven you have the Shade plugin and others, see https://www.baeldung.com/executable-jar-with-maven

Tailoring the build of downstream applications is something that should be done at downstream level, not in EchoSVG's build.

[rschmunk]

@carlosame, I'm building using the sample gradle commands from the shell. The simple "./gradlew uberjar" command is what's resulting in an 8 MB jar when I do so.

If I go to the Batik website and download their built release, the included "batik-all-1.17.jar" is 4 MB. I can slot that jar right in with one of my apps and be able to write out an SVG document to disk using the same Graphics2D calls that the app uses for rendering in the UI on-screen.

[carlosame]

So you are using the svggen module. I just added the ability to create fat jars for individual modules, it is now explained in the README as well as the wiki.

So if you execute:

./gradlew echosvg-svggen-jar-with-deps

you obtain echosvg-svggen/build/libs/echosvg-svggen-1.1-SNAPSHOT-with-deps.jar which is what you want (and it is only 1.7MB).

[rschmunk]

@carlosame, I found that just the echosvg-svggen-1.1-SNAPSHOT-with-deps.jar was not enough to write an SVG file to disk as a GenericDOMImplementation object is required to construct a SVGGraphics2D. That meant adding echosvg-dom to the classpath, and it needed to be the with-deps jar.

Also, for cases where my need to write SVG output with a bitmap embedded, then it was necessary to replace echosvg-svggen with echosvg-svgrasterizer---width-deps. Which is a hefty 7 MB.

[carlosame]

@carlosame, I found that just the echosvg-svggen-1.1-SNAPSHOT-with-deps.jar was not enough to write an SVG file to disk as a GenericDOMImplementation object is required to construct a SVGGraphics2D. That meant adding echosvg-dom to the classpath, and it needed to be the with-deps jar.

Are you sure? AFAIK it can use any DOM implementation, not necessarily EchoSVG's. I mean you could use the default DOM provided by the JDK (haven't tested that though).

BTW if you prefer to use a SVGOM or any other DOM, that's up to you to add it to the classpath. That's why I wrote that this should be handled by the build process of your (downstream) application and not by EchoSVG's.

Also, for cases where my need to write SVG output with a bitmap embedded, then it was necessary to replace echosvg-svggen with echosvg-svgrasterizer---width-deps. Which is a hefty 7 MB.

As explained in my first reply, the dependencies of EchoSVG are essentially the same as Batik's (except for the CSS engine and its dependencies). In fact you save a couple of Batik dependencies that this project does not need. You may be fine without Rhino, xmlgraphics-commons, etc., but your users could be a keystroke away from a ClassNotFoundException.

I'm moving this to Discussions, as little more can be done by the EchoSVG build system.

[rschmunk]

TBH, I did not consider using a generic DOM object. I got started on this using an example from the Batik website that uses their class GenericDOMImplementation, so I went looking for Echo's analog thereof.

Sorry if it seems like I'm giving you grief. I'm just trying to figure out how to include the minimal necessary single additional JAR in my app distros. The Batik "all" jar was blowing up one of the apps about 25%.

I'll take another look at this tomorrow and see if another DOM will work.

[carlosame]

I'm just trying to figure out how to include the minimal necessary single additional JAR in my app distros.

Only by inspection (visual or by a tool) of the EchoSVG code paths that your program uses, you can rigorously decide which dependency you can ignore. Or you could just make 'experiments' but that's risky.

The Batik "all" jar was blowing on of the apps up about 25%.

Web standards are hard to implement (Drew DeVault compared it to the Apollo or the Manhattan projects), so you should be happy that you are only dealing with 7MB and not 100.

[carlosame]

FWIW I just removed the echosvg-css module dependency on xmlgraphics-commons, so the -with-deps archive is now smaller.

If you are simply running batik-all without the dependencies, this means that for example if you attempt to transcode a document which contains an <image> element, it is going to crash. Please don't do that.

[carlosame]

New wiki page about SVG Generator, with an example that uses the JDK built-in DOM. Yes it works.

[rschmunk]

That's very nice. Thank you. Generally works very well when the only Echo jar in my class path is echosvg-svggen-*-with-deps.

The one problem I still confront is that for some use cases, my apps may need to call Graphics2D.drawImage to include a bitmap image in the output SVG. It's apparently necessary for Echo's svgrasterizer jar to also be in the classpath for that to succeed?

Curiously, if the svgrasterizer jar is not present, I still get SVG output without error. The bitmap image is just not included.

Also, any time you want to cut this off, that's okay. I'm just trying to figure out how to add a requested feature to my apps with the least personal effort. No reason that someone else should have to put in that effort.

[carlosame]

The one problem I still confront is that for some use cases, my apps may need to call Graphics2D.drawImage to include a bitmap image in the output SVG. It's apparently necessary for Echo's svgrasterizer jar to also be in the classpath for that to succeed?

Curiously, if the svgrasterizer jar is not present, I still get SVG output without error. The bitmap image is just not included.

No you do not need svgrasterizer, you need transcoder (in Batik codec) because you need an image writer. Look at this line:

echosvg/echosvg-svggen/src/main/java/io/sf/carte/echosvg/svggen/ImageHandlerBase64Encoder.java

Lines 147 to 148 in 331be27

	ImageWriter writer = ImageWriterRegistry.getInstance().getWriterFor("image/png");
	writer.writeImage(buf, os);

So what you need is echosvg-transcoder-<version>-with-deps.jar which comes from

./gradlew echosvg-transcoder-jar-with-deps

It's 7.1MB which isn't that bad in terms of implementations of web standards.

My impression is that the codec and transcoder packages could be refactored in a way that the base interfaces (and a few abstract classes) could belong to a separate module, and then the dependencies of both would be much cleaner. But doing that would imply that the package distribution of EchoSVG would be incompatible with Batik, and one could no longer switch from Batik to EchoSVG by just switching org.apache.batik by io...echosvg in the package names.

So here we are.

[carlosame]

The one problem I still confront is that for some use cases, my apps may need to call Graphics2D.drawImage to include a bitmap image in the output SVG. It's apparently necessary for Echo's svgrasterizer jar to also be in the classpath for that to succeed?
Curiously, if the svgrasterizer jar is not present, I still get SVG output without error. The bitmap image is just not included.

So what you need is echosvg-transcoder-<version>-with-deps.jar which comes from

Forget about this. I reorganized the codec packages and moved the classes that had the circular dependency issues. Those classes aren't visible anymore. There is a very small price in backwards compatibility (3 classes aren't visible anymore) but IMO well worth it.

With only 1.8MB, the echosvg-svggen-<version>-with-deps.jar archive should now contain everything you need. Let me know if it works for you.

[carlosame]

Version 1.1 is out and, as I heard no news, I assume that you didn't find any subsequent issues. Can we close this?

[rschmunk]

@carlosame , I got distracted by another couple things and haven't really looked at this in the past week or more. Will try to do so in the next couple days.

[rschmunk]

@carlosame, Go ahead and close this. With the 1.1.1 and 1.2 releases, I am able use just the svgrasterizer-with-deps in the release downloads to write out a clean SVG file from one of my apps, even though in some tests it was calling Graphics2D.drawImage(...) to include a bitmap image in the plot. Or at least clean enough that Adobe Illustrator opens the files with no complaints.

However, I'm still a bit bothered by the jar size, which I know is a petty complaint this day and age. But I have other things that really demand my attention now, so I will let this lie aside until I have a few more users say that they would like SVG output.

[rschmunk]

I may have mis-typed. It was late.

[rschmunk]

Okay, I've gone back several times and tried using echosvg to output an SVG file that includes a bitmap image inserted using Graphics2D.drawImage(...), and using the svggen jar only (and definitely not svgrasterizer). It works for three different apps on three different machine. This also includes building echo-svggen-jar-with-deps from scratch from the 1.2.1 source.

Sorry to be a pest.

[carlosame]

Thanks for following-up. Bitmaps definitely aren't a problem now, with the correct dependencies being declared. Glad to see that you didn't have further issues.

[rschmunk]

I have had a problem on one machine with one app writing out an SVG that causes Adobe Illustrator to puke a missing font error when opening the file, which is odd for a couple reasons:

• The three machines are all the same OS and OS version (macOS Sonoma), and the same Java JDK and Java version.
• The example SVG in question doesn't even have any text in it.
• Photoshop on that machine opened the example SVG without complaint.

I'd have explored this more, but AI had been giving me authentication trouble on that particular machine.

I'm not too troubled about this, and the users who have asked about SVG output don't seem to be the type who use Adobe software anyway.

Edit: Not exactly a font problem. And I just found the same Illustrator error reported on their forums in 2009 (!) by someone trying to work with an SVG file.

[carlosame]

I have had a problem on one machine with one app writing out an SVG that causes Adobe Illustrator to puke a missing font error when opening the file, which is odd for a couple reasons:

[...]

* The example SVG in question doesn't even have any text in it.

Even if your image doesn't have any text in it, there could be a font-family attribute in the <svg> element (a default font).

Edit: Not exactly a font problem. And I just found the same Illustrator error reported on their forums in 2009 (!) by someone trying to work with an SVG file.

To use fonts properly, one could set a default style sheet (either manually via DOM or using a StyleHandler like in the "Customizing the generated SVG style" section of the Batik examples) with a list of default fonts, instead of just a single default one.