SVG Import Source Code

From Apache OpenOffice Wiki
Jump to: navigation, search

This page is archived for historical reasons only. It is no longer maintained and information may not be current.

SVG Import
(external impl.)
Source code
Group opacity
Elliptic arcs
Path semantics
Coordinate systems

There is some interest in integrating the filter into the project. Until this completed, you can checkout the sources from my SVN repository. This pages describes how to get the sources and build the filter yourself.

Be warned: The sources are currently not in the best condition. Much documentation is still missing. To get started anyway, you need at least some overview of the project. I quote the following from my mail to

The SVG import filter project currently consists of several sub-projects that are described below. Extension (svg-import)

This provides a XImportFilter. This filter builds an annotated SVG DOM tree using Batik, transforms it into an OpenDocument DOM tree using svg2office and finally translates the resulting OpenDocument DOM into SAX events, which are fed into the XDocumentHandler that is provided by

SVG to ODG Transformation kernel (svg2office)

The svg2office transformation is structured as visitor of a SVG DOM tree, which is provided by Batik. During its visit, the transformation builds OpenDocument DOM nodes. For the OpenDocument DOM, currently, a generic DOM implementation is used (provided by [Java:javax/xml/parsers/DocumentBuilder javax.xml]). To avoid writing string constants and to have at least some sort of type checking and IDE support, facade classes are generated directly from the RelaxNG schema of the OpenDocument specification.

The transformation itself mainly relies on the information provided by the SVG DOM API as specified by Only where this is not sufficient, implementation details from the Apache Batik SVG engine are used. This means, that the transformation is not built as Batik backend (a transcoder that acts on behalf of the Batik-internal GVT rendering tree). The Batik-internal GVT rendering tree is therefore only consulted, where context information is required, which is not offered by the SVG DOM.

Java OpenDocument Processing ( is a library for manipulating OpenDocument documents in pure Java.

Various Utilities

  • haui.collections is a rudimentary library for sequences.
  • net.sf.wtk.xml is a library for visitor-based XML DOM processing.
  • net.sf.wtk.ant.namespaces a tool for introducing namepaces into Apache Ant build files to describe dependencies among projects.
  • net.sf.wtk.ant.maven a stub for the Apache Ant libraries for automatically downloading dependencies from Maven repositories.

Apache Batik SVG Engine (xml-batik)

A (minimally) hacked version of xml-batik. That's a pity, but batik was not primarily designed to offer it's SVG DOM to third parties. All transcoders in batik rely on the internal GVT tree for rendering, not for transformation. Therefore, the implementation of some "advanced" features of the SVG DOM (like non-exposed subtrees for certain elements) are not yet implemented. To make svg-import more complete, some more effort is necessary to evolve missing features in batik.

Checking out the sources

To get started, you have to check out all four projects from SVN. The best way to do that is to change to your (Eclipse) workspace directory and type the following commands:

1. Check out svg-import:

svn --username anonymous --password '' co \

2. Check out svg2office:

svn --username anonymous --password '' co \

3. Check out

svn --username anonymous --password '' co \

4. Check out haui.collections:

svn --username anonymous --password '' co \

5. Check out net.sf.wtk dependencies:

svn co
svn co
svn co

6. Check out a matching revision of xml-batik:

svn co -r571815 \ xml-batik

Building the sources

Afterwards, you have to apply the patches to batik. The patch file is provided in svg2office/patches. If your current working directory is your workspace, the following should do:

cd xml-batik
patch -p0 < ../svg2office/patches/xml-batik-r571815.patch
cd ..

All projects are prepared for building with either Eclipse or Apache Ant (

Ant build files have propper dependencies so that building the top-most project (svg-import) automatically builds all dependencies. The only dependency that has to be resolved manually is the dependency to your local installation for accessing the UNO runtime interface libraries. Therefore, the path to your local OpenOffice installation must be entered into the following properties file:

cd svg-import
cd ..

Now, you are ready to build the extension:

cd svg-import
ant extension

If everything went fine, you find a home-browen SVG import filter svg-import.oxt in the directory svg-import/build, which can be installed into using the integrated package manager.

Last update: Haui 21:43, 5 September 2007 (CEST) for building version 1.2.2 of the import filter.

Personal tools