Proposals/SVG in ODF

From SVG
(Redirected from SVG in ODF)


SVG in the OpenDocument Format dates back to 2005, when the OpenDocument TC, a technical committee in OASIS, decided to use SVG in the OpenDocument office format. Rather than use SVG as specified, however, they merged it with their own custom format Draw/Impress. They decided that many SVG-defined attributes were useful, but not the elements. Not realizing that SVG attributes are in the null namespace, they applied these attributes to Draw elements but put them in the SVG namespace.

After some discussion between the OpenDocument TC and the SVG WG, this ended in an acceptable (if not entirely satisfying) result, in which the ODF specification changed the namespace in which they placed their referenced attributes from the SVG namespace to their own custom namespace, "urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0".

Current State

Right now, ODF (and more specifically, the implementation) only supports SVG as an import and export format, not as a native format. An OOXML developer, Jesper Lund Stocholm, wrote a blog entry with in-depth analysis of this support, and determined that there doesn't seem to be true SVG support.

Inkscape also has compiled a list of correspondancies between ODF Draw and SVG.

While there is clearly some interest within the OOo development team to provide native SVG support, there also seems to be some resistance; at least some of these developers seem determined to retain the Draw/Impress format as the primary graphics format, and to devote the majority of effort there, as discussed in this Sun blog entry.

Our goal is to convince the OpenDocument TC to mandate full native support for SVG 1.1 and SVG Tiny 1.2 in ODF-Next. Important things for us to note include:

  • we are not challenging the existing support for Draw/Impress; SVG would supplement that
  • we are not proposing that SVG replace the whole format (there seemed to be some confusion about that on the Sun blog comments)
  • we are willing to adapt SVG to meet their needs
  • there are substantial network effect benefits to SVG
  • there are people inside and outside the dedicated SVG community who want to see this happen and who would benefit

ODF Requirements

Andreas Neumann alerted us to a Call for Proposals for "ODF-Next", from OASIS's Mary McRae. ODF-Next is the provisional name for the version of the spec after ODF 1.2.


We have to submit our requirements by March 31st, 2009 to be considered for their report, which is due May 1st, 2009. This will be composed by the ODF Requirements Subcommittee.



Previously, we had been in touch with Michael Brauer (Michael.Brauer@Sun.COM) about this issue. He still seems involved in this project, according to the OpenDocument TC feedback page. This page lists the following contacts:

Additionally, there is a ODF Requirements Subcommittee chair:

Mailing List

We need to send our comments to by March 31, 2009. We can look through the archives to find how best to phrase and format our request.

Proposed Liaison Prose

+NAME Doug Schepers


+CATEGORY (select one or more from below) editing/import-export/other

+SCOPE (select one or more from below) presentation/other

+USE CASE Dynamic, interactive, semantically-rich, Web-friendly, reusable graphics

We applaud the OpenDocument TC for their decision to use SVG, by adopting some SVG elements and attributes. As we understand it, one goal of the ODF specification is to reuse existing specification where appropriate, and in this case, it makes sense to specify complete support for SVG 1.1 and SVG Tiny 1.2 as they are specified, rather than only as part of ODF Draw format. In the next version of the ODF specification, there should be support for SVG as a regular image and as vector graphics (or "line art"), in addition to the ODF Draw format.

With native SVG support, ODF would enjoy several "network effects" though the increasing prevalence of SVG among authoring tools and viewers. Developing and maintaining ODF implementations would be made simpler, since there are many existing open-source SVG libraries, in both C and Java.

In contrast to ODF Draw format, SVG is natively web-publishable, with native support in Firefox, Opera, Safari, and Google Chrome, and in Internet Explorer through plugins. While ODF currently supports SVG as both an import and export format, this extra step makes effective round-tripping more difficult, with regards to using existing content, and editing in Inkscape, Illustrator, CorelDraw, Xara, and other major graphics authoring tools.

Additionally, there is good existing clipart content through various open online clipart repositories, which would add value to ODF by making it easier to author content through reuse. This would also tie ODF into the growing SVG and open-graphics communities. With the recent addition of SVG/VML drawings to Google Docs, this would also provide a common graphics format for two of the most popular office suites.

Where the SVG specification may not meet the needs of ODF, there are two options. First, ODF can simply extend SVG using its own namespaced elements and attributes. Second, the SVG WG is interested in working with the OpenDocument TC to add missing features to the SVG specification. We are already planning on adding some common features, like connector elements, which we see are supported in ODF, and we are open to hearing more use cases and requirements.

We feel that this is a pivotal opportunity for open document formats, and that a synergy between ODF and SVG will work to everyone's benefit.

Please let us know any issues or factors that would make adopting SVG as a first-class component of ODF difficult. We may be able to help remove barriers or clarify confusion.

+DESCRIPTION Reference SVG 1.1 and SVG Tiny 1.2 as mandated formats for ODF-Next, as a regular image and as vector graphics: 

For extensions of SVG, ODF should follow the guidelines detailed in the SVG specification:

Currently, SVG is allowed in ODF, as stated in 9.3.2 Image, "While the image data may have an arbitrary format, it is recommended that vector graphics are stored in the [SVG] format and bitmap graphics in the [PNG] format." However, there is no mandate that it be supported, or details about the precise manner in which it should be supported. After a brief review of the OpenDocument specification, we recommend that you add more detail regarding SVG in the following sections:

4.5 Page-bound graphical content
5.8 Inline graphics and text-boxes
9.3.2 Image, to allow SVG as a link to an external resource, or embedded directly in a document
9.3.3 Objects, to allow SVG as Charts or Drawings
9.3.10 Client Side Image Maps
13 SMIL Animations, to match SVG's animation functionality.

The SVG WG is available to help provide more details during the OpenDocument specification process.