-
Notifications
You must be signed in to change notification settings - Fork 2
If you use a transcoder that inherits from the XMLAbstractTranscoder
class, you can. In version 1.x you have to set the following hints (not in version 2.x):
transcoder.addTranscodingHint(XMLAbstractTranscoder.KEY_DOCUMENT_ELEMENT_NAMESPACE_URI,
"http://www.w3.org/1999/xhtml");
transcoder.addTranscodingHint(XMLAbstractTranscoder.KEY_DOCUMENT_ELEMENT, "html");
The first SVG element found is used as the new root, although you can pick a specific svg
element if you use the KEY_SVG_SELECTOR
transcoding hint.
You could also use the CSSTranscodingHelper
which works similarly.
In the rest of the old API, you can't (please see #40). You have to import the SVG subtree into a new SVG DOM document.
See above, you have to appropriately set the KEY_DOCUMENT_ELEMENT_NAMESPACE_URI
and KEY_DOCUMENT_ELEMENT
hints.
Note: this should not be a problem in version 2.0 or higher.
This arises when your build process does not use the provided dependency metadata, and you do not have css4j in your classpath or modulepath.
You may want to consider using one of the fat jars that this project provides, like echosvg-transcoder-svg-<version>-with-deps.jar
or even the full echosvg-all-<version>-alldeps.jar
.
Look at the downloads provided at the Releases page.
This happens when your build process does not use the provided dependency metadata, and you do not have xml-dtd in your classpath or modulepath.
You may want to consider using one of the fat jars that this project provides, like echosvg-transcoder-svg-<version>-with-deps.jar
or even the full echosvg-all-<version>-alldeps.jar
.
Look at the downloads provided at the Releases page.
EchoSVG uses the java.awt
package which is not available on Android. Although a library like android-awt may be used, this project is unaware of anyone succeeding. Also, a parser-related issue has been reported.
EchoSVG implements part of the CSS Object Model, and allows programmatic manipulation of CSS style sheets.
If you want to use a more powerful CSS OM, you may want to pre-process your document with css4j first, then feed it to EchoSVG.
Does this project support Houdini's Typed OM?
Version 1.x uses the old (and deprecated) CSSValue
API, while 2.0 is a first transition towards Typed OM. In 2.0 you can use the Typed OM API from both Java and document-embedded Javascript scripts. Your scripts won't be 100% compatible with browsers though (more work is required for that).
The following tutorials may help:
- "SVG Viewport and viewBox (For Complete Beginners)" by K. Bracey
- "SVG Viewport and View Box" by J. Jenkov
- "Understand the SVG Viewbox" by P. Ryan (Oriented to browsers and Javascript)
As well as the MDN reference for the viewBox
: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox
No it is not, as its maintainer does not accept Maven Central's Terms of Use (see issue #95). The distribution is through the css4j Maven repository instead.
Only software coming from the Apache Software Foundation (ASF) source repositories can be used in org.apache
packages. If you look at the point 6 of the ASF license 2.0:
- Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
The term "Apache" is a registered trademark by the ASF (registration number 5906264) and can only be used for attribution. "Apache Batik" is a product name and similar considerations apply.
No you cannot. Submitting code to any Apache Software Foundation (ASF) project implies assigning the copyright to the ASF. Instead, EchoSVG uses a Developer Certificate of Origin copyright model, so contributors keep their copyright.
You cannot assign to the ASF the copyright that you do not own.
The codec
and transcoder
jar files were a bit entangled in Apache Batik, as they have a runtime circular dependency. And this often confused people, see:
- https://stackoverflow.com/questions/45239099/apache-batik-no-writeadapter-is-available
- https://bz.apache.org/bugzilla/show_bug.cgi?id=44682
What's worse, in Batik a third module silently depends on codec
at runtime but doesn't declare that in the POM, so in the end the circularity involves three modules.
To fix that mess, in EchoSVG the WriteAdapter
implementations were moved from echosvg-codec
to the transcoder.image
package of echosvg-transcoder
.
Yes, but in your build you have to configure exclusions for the xml-apis-ext
(EchoSVG provides an improved replacement) and xml-apis
artifacts, also add the org.w3c.css:sac
artifact.
In Apache Maven:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>batik-transcoder</artifactId>
<version>1.18</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<!-- Already available from java.xml -->
<groupId>xml-apis</groupId>
<!-- Use EchoSVG dependencies instead of xml-apis-ext -->
<artifactId>xml-apis-ext</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>batik-codec</artifactId>
<version>1.18</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<!-- Already available from java.xml -->
<groupId>xml-apis</groupId>
<!-- Use EchoSVG dependencies instead of xml-apis-ext -->
<artifactId>xml-apis-ext</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Needed due to xml-apis-ext exclusion -->
<dependency>
<groupId>org.w3c.css</groupId>
<artifactId>sac</artifactId>
<version>1.3</version>
</dependency>
In Gradle:
dependencies {
// Other dependencies go here
implementation ('org.apache.xmlgraphics:batik-transcoder:1.18') {
// Already available from java.xml
exclude group: 'xml-apis', module: 'xml-apis'
// Use EchoSVG dependencies instead
exclude group: 'xml-apis', module: 'xml-apis-ext'
}
implementation ('org.apache.xmlgraphics:batik-codec:1.18') {
// Already available from java.xml
exclude group: 'xml-apis', module: 'xml-apis'
// Use EchoSVG dependencies instead
exclude group: 'xml-apis', module: 'xml-apis-ext'
}
implementation 'org.w3c.css:sac:1.3' // Required due to xml-apis-ext exclusion
}
The API dependencies that EchoSVG uses not only are properly modularized, they also support modern SVG and CSSOM interfaces while being compatible with the old xml-apis-ext
.
It is a false positive. The security scanner expects a feature like load-external-dtd
or disallow-doctype-decl
being used, however those configurations lead to data loss when XML entities are used.
EchoSVG uses the xml-dtd resolver as described in the aforementioned post.
Yes there are a few open source projects that use EchoSVG, and Carte is a relatively simple one that you could look at (see SVGtoRaster.java).
For a much simpler example, see EchoSVGTest.java.