OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-comment] Requirement: SVG Integration

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.


2009/3/26 Doug Schepers <schepers@w3.org>:
> Doug Schepers
> schepers@w3.org
> +CATEGORY (select one or more from below)
> editing/import-export/other
> +SCOPE (select one or more from below)
> presentation/other
> 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.
> 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: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]