Skip to content

2.0

Latest
Latest
Compare
Choose a tag to compare
@carlosame carlosame released this 27 Feb 14:40
· 2 commits to master since this release
v2.0
This tag was signed with the committer’s verified signature. The key has expired.
carlosame
GPG key ID: 36413FEC3F9E2484
Expired
Verified
Learn about vigilant mode.
e4e66db

All users are encouraged to upgrade, as the 1.x branch will now only receive security updates. Version 2.0 is new, but it passes far more tests than 1.2.4.

Highlights


Advanced CSS

Adds native support for several CSS improvements, which until now required the use of the Transcoding Helper but now are available out-of-the-box.

fill: var(--my-color, blue);
@property --my-length {
  syntax: "<length>";
  inherits: true;
  initial-value: 4px;
}
@supports (color: oklch(67% 0.18 270)) {
  g {
    --my-color: oklch(45% 0.3 264);
    --my-stroke-width: calc(1px + var(--my-length));
  }
}
@media screen and (300px < width <= 1000px) and (prefers-color-scheme: light) {
  text.myclass {
    font-size: calc(var(--my-FontSize) + 2pt);
  }
}

See also KEY_MEDIA.

  • The turn, Q, vw, vh, vmin, vmax, lh, rlh, rem and rex units.

  • calc() expressions, both in CSS properties/attributes and non-CSS attributes. You can write y = "calc(30% + 2vmin)" for example, like you'd do with modern web browsers.

  • The advanced attr() value that was recently implemented by Chromium-based web browsers.

ellipse {
  fill: attr(data-color type(<color>), #22a);
}
  • The initial, unset and revert CSS-wide keywords (this being SVG, revert is currently handled as unset).

Standards-compliant Resolution

In addition, 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).


The transcoder module was split 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 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 full 2.0 transcoder with dependencies fills a jar of 6.34 MB, while the specific SVG-to-image transcoder becomes a bit smaller (6.04 MB).

The gains are higher for the WMF to SVG case (3.38 MB) or the SVG-to-SVG (2.64 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

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. The color profile is automatically embedded in the resulting image, if needed.

Most of the color conversions are done via the AWT toolkit and, when converting a color to a smaller gamut (where that color isn't represented), it doesn't attempt any gamut mapping. Moreover there are several elements in the SVG specification where the sRGB color space is assumed (e.g. the filter primitives), and if one combines one of those with an out-of-gamut color, the results are less than perfect.

The CSSTranscodingHelper restricts the used colors to the Display P3 and A98 RGB gamuts, doing an accurate gamut mapping. If your SVG image includes colors outside of those gamuts, you may obtain better results using that tool.

Disclaimer

I only have access to devices with sRGB displays, so haven't visually checked the color-profiled PNG/JPG images. In that sense, the color profile support should be considered as untested. But the profiles are indeed in the images, and the pixel values seem correct.


Upgrading

If your build uses Gradle, do not forget to allow the download of the new dependencies from the Maven repository, with an includeGroupByRegex or similar:

repositories {
    maven {
        url = "https://css4j.github.io/maven/"
        mavenContent {
            releasesOnly()
        }
        content {
            includeGroupByRegex 'io\\.sf\\..*'

            // Alternative to the regex:
            //includeGroup 'io.sf.carte'
            //includeGroup 'io.sf.jclf'
            //includeGroup 'io.sf.graphics'
            //includeGroup 'io.sf.w3'
        }
    }
}

If you find any issue upgrading, please check MIGRATING_FROM_BATIK. Open an issue or discussion if necessary.

Assets 12
Loading