Thank you for this contribution Doug. I note that this is not the
first request for "first class" SVG support in ODF. I will ensure
that this requirement is prominent on the agenda.
Regards
Bob
2009/3/26 Doug Schepers <>:
> +NAME
> Doug Schepers
>
> +CONTACT
>
>
> +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
>
> The W3C SVG Working Group applauds 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 inherently web-publishable, with
> native support in Firefox, Opera, Safari, and Google Chrome, and in Internet
> Explorer through plugins or script adaptions. While OOo 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.
>
>
> Note that OOo, while it does have some support for SVG, does not treat SVG
> as a first-class format, as outlined here:
> http://idippedut.dk/post/2008/01/Embrace-and-extend---SVG-revisited.aspx
>
> By clarify how SVG should be supported, there would be much better
> interoperability.
>
>
> +DESCRIPTION
> Reference SVG 1.1 and SVG Tiny 1.2 as mandated formats for ODF-Next, as a
> regular image and as vector graphics:
> http://www.w3.org/TR/SVG11/
> http://www.w3.org/TR/SVGTiny12/
>
> For extensions of SVG, ODF should follow the guidelines detailed in the SVG
> specification:
> http://www.w3.org/TR/SVGTiny12/extend.html#ForeignNamespacesPrivateData
>
> 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.
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe:
> Unsubscribe:
> List help:
> List archive: http://lists.oasis-open.org/archives/office-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
>
>
