[OASIS Issue Tracker] (OFFICE-3995) Allow native SVG instead of <office:binary-data> for images

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OFFICE-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=70540#comment-70540 ] 

Michael Stahl commented on OFFICE-3995:
---------------------------------------

there was a question regarding the different use of <empty> in the schema:

{noformat}
    <rng:element name="draw:fill-image">
      <rng:ref name="draw-fill-image-attlist"/>
      <rng:choice>
        <rng:group>
          <rng:ref name="common-draw-data-attlist"/>
          <rng:empty/>
        </rng:group>
        <rng:ref name="office-binary-data"/>
      </rng:choice>
      <!-- https://issues.oasis-open.org/browse/OFFICE-3933 -->
    </rng:element>
{noformat}

here the <rng:empty> element is redundant - the <rng:group> that contains it can be replaced by the other child <rng:ref> element (see Relax NG specification, 4.21. empty element).

{noformat}
      <rng:element name="style:background-image">
        <rng:ref name="style-background-image-attlist"/>
        <rng:choice>
          <rng:ref name="common-draw-data-attlist"/>
          <rng:ref name="office-binary-data"/>
          <rng:empty/>
        </rng:choice>
      </rng:element>
{noformat}

here the <empty> element is a real alternative to the other options, i.e. the <style:background-image> may not contain any definition of an image source.

perhaps this is intentional - the background-image occurs in styles, and perhaps the idea here is  that a parent style could have defined an image source and the <empty> effectively means to inherit from the parent.

> Allow native SVG instead of <office:binary-data> for images
> -----------------------------------------------------------
>
>                 Key: OFFICE-3995
>                 URL: https://issues.oasis-open.org/browse/OFFICE-3995
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: New Feature
>            Reporter: Regina Henschel
>            Priority: Major
>             Fix For: ODF 1.4
>
>
> Currently applications need to use the <office:binary-data> element to store an embedded SVG-image, in case they will save to a single XML file (flat ODF). That means that the SVG-image has to be encoded to BASE64. But an SVG-image is an XML-document and therefore it would be possible to use it directly, similar as done with MathML objects. The proposal has the changes that allow use of native SVG for images where now <office:binary-data> is needed.
> Remarks to the proposal:
> The namespace attribute in element <svg:svg> is needed, because OpenDocument producer bind the prefix "svg" to the namespace "urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0".
> The referenced document is a Candidate Recommendation. In case it will be released until the release of ODF 1.4, the URL has to be adapted.
> I'm not sure, whether the restriction "at most one" is correctly described by the schema.
> My proposal is not, to use <svg:svg> instead of the <draw:image>, because then the useful attributes draw:mime-type and draw:filter-name, and using <text:p> element for e.g. a caption would not be possible. And the proposal is not about adding an <svg:svg> element as drawing object on same level as e.g. <draw:rect>.
> Defining svg-svg follows the way it is done for math-math.
> I'm not sure, whether to force xlink in case of package format. That needs discussion.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)