Split the transcoder module in 4 modules: api, svg, svg2svg and tosvg #116
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes an SVG library is embedded into an executable, and a common concern for both EchoSVG and Batik users in those cases is to make the size of the embedded modules as small as possible. Notably, in the case of the Transcoder a number of unneeded classes may be included. For an example of such concern see eclipse-platform/eclipse.platform.swt#1438 (comment) The current `transcoder` module was designed as a monolithic do-it-all package, with users always carrying code that they do not intend to run. But it can be split in several submodules, in a way that backwards compatibility is kept (the old `transcoder` module still exists and provides all the classes), so users willing to minimize their dependencies can choose a smaller specific sub-module. This commit splits the transcoder in 4 modules: - `transcoder-api` (API) - `transcoder-svg` (SVG to image) - `transcoder-svg2svg` (SVG to SVG) - `transcoder-tosvg` (conversions to SVG, currently only WMF to SVG) In the typical case of rendering SVG as a PNG, the current 2.0 transcoder with dependencies fills a jar of 6.26 MB, while the specific SVG-to-image transcoder becomes a bit smaller (5.98 MB). The gains are higher for the WMF to SVG case (3.94 MB) or the SVG-to-SVG (3.60 MB). Note that there is plenty of room for improvement in conversions to SVG, because the current code uses the SVG DOM implementation provided by the `anim` module (with all its dependencies) but the JDK DOM implementation could be used instead (like in the EchoSVG Wiki example for `SVGGraphics2D`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sometimes an SVG library is embedded into an executable, and a common concern for both EchoSVG and Batik users in those cases is to make the size of the embedded modules as small as possible.
Notably, in the case of the Transcoder a number of unneeded classes may be included. For an example of such concern see
eclipse-platform/eclipse.platform.swt#1438 (comment)
The current
transcodermodule was designed as a monolithic do-it-all package, with users always carrying code that they do not intend to run. But it can be split in several submodules, in a way that backwards compatibility is kept (the oldtranscodermodule still exists and provides all the classes), so users willing to minimize their dependencies can choose a smaller specific sub-module.This PR splits the transcoder in 4 modules:
transcoder-api(API)transcoder-svg(SVG to image)transcoder-svg2svg(SVG to SVG)transcoder-tosvg(conversions to SVG, currently only WMF to SVG)In the typical case of rendering SVG as a PNG, the current 2.0 transcoder with dependencies fills a jar of 6.26 MB, while the specific SVG-to-image transcoder becomes a bit smaller (5.98 MB).
The gains are higher for the WMF to SVG case (3.94 MB) or the SVG-to-SVG (3.60 MB). Note that there is plenty of room for improvement in conversions to SVG, because the current code uses the SVG DOM implementation provided by the
animmodule (with all its dependencies) but the JDK DOM implementation could be used instead (like in the EchoSVG Wiki example forSVGGraphics2D).