2.0 preview 1
Pre-release
This first preview of 2.0 is mainly intended to check how the transcoder module split is received, as it is a potentially controversial change. It could always be reverted or done differently.
Summary of the new features in 2.0:
Support for advanced CSS
Adds native supports for several CSS improvements, which until now required the use of the Transcoder Helper but now are available out-of-the-box.
-
Custom properties (
var()function). -
The
@propertyrule (registered custom properties). -
Media Queries level 4, including the
prefers-color-schememedia feature. As a result, theKEY_PREFERS_COLOR_SCHEMEtranscoding hint was added. -
The
vw,vh,vmin,vmax,lh,rlh,remandrexunits. -
calc()expressions, both in CSS properties/attributes and non-CSS attributes. -
The
initial,unsetandrevertCSS-wide keywords (this being SVG,revertis currently handled asunset). -
The advanced
attr()value that Google Chrome 133 is shipping.
In addition to this, it implements a true resolution concept: the resolution is no longer used in CSS unit conversions, matching the standards-compliant behaviour of web browsers. That resolution is also available to CSS Media Queries.
To make it available to the transcoder, the KEY_RESOLUTION_DPI transcoding hint was added. The old KEY_PIXEL_UNIT_TO_MILLIMETER transcoding hint can still be used, but is no longer used in CSS unit conversions (only in the encoding phase).
Split the transcoder module in 4 sub-modules: api, svg, svg2svg and tosvg
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. For example, the code to convert WMF to SVG was always there even if you just wanted to convert SVG to PNG.
So it was 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.
Version 2.0-pre1 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 2.0-pre1 transcoder with dependencies fills a jar of 6.33 MB, while the specific SVG-to-image transcoder becomes a bit smaller (6.03 MB).
The gains are higher for the WMF to SVG case (3.37 MB) or the SVG-to-SVG (2.59 MB).
More flexible DOM (and transcoding from SVG)
Until now, before transcoding a file one has to specify whether it is SVG or HTML via the KEY_DOCUMENT_ELEMENT and KEY_DOCUMENT_ELEMENT_NAMESPACE_URI hints. Now the DOM factories use a different procedure, and in consequence those transcoding hints are ignored. For example if you are using the SVG-to-PNG transcoder, it will always look for SVG in any provided document.
However, if the file being processed is HTML instead of XHTML you still have to specify an HTML parser as explained in the wiki.
Transcoding with color profiles (warning: experimental)
If you transcode an SVG image which uses colors outside of the sRGB color palette (e.g. color(display-p3 1 1 0)), EchoSVG determines the smallest color gamut that fits your image and subsequently uses it.
Unfortunately the color conversions are done via the AWT toolkit and aren't very precise. Moreover there are several places in the codebase where the sRGB color space is assumed, and the results are less than perfect.
If the SVG that you want to transcode uses color spaces outside of the sRGB gamut, you may want to consider using the CSSTranscodingHelper instead, as it uses the css4j color conversions which are more accurate (similar results to ColorJS).