[OASIS Issue Tracker] Commented: (OFFICE-3465) ODF CD05-1 10.4.4<draw:image> use of <office:binary-data> unimplementable

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

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22021#action_22021 ] 

Dennis Hamilton commented on OFFICE-3465:
-----------------------------------------

Andres,

I may have used "image" in a too-restrictive sense when talking about the <draw:frame> and it would have been better to say "graphic", using th nomenclature of section 10.4.1 on general characteristics of frames.  Is that better.

Coming back to this specific issue, note that:

The *only* place <draw:image> is used in an ODF 1.2 document is in <draw:frame>.   I am addressing specifically the case of the <office:binary-data> element within the <draw:image> element of a <draw:frame>.

There are separate issues on <office:binary-data> in other elements and the <draw:image> form that has an xlink:href attribute and no <office:binary-data> child.

I agree that a <draw:image> can occur in a <draw:frame> as an alternative presentation for something that is much more complicated, using one of the alternative permitted children for a <draw:frame>.    And there may be multiple <draw:image> children to choose from also.

 but I think the higher-level considerations of how to use alternative children in a frame, including alternative <draw:image> elements among them, should be addressed in the description of <draw:frame> and not under <draw:image>.  I find it too inverted to put it all under <draw:image>.

Finally, since maybe that is not what you are concerned about, I also definitely agree that there should be some well-known graphic formats for use as choices in a <draw:frame>, including some in <draw:image>.  

It seems to me that the problem of decoding the <office:binary-data> has nothing to do with SVG and other XML/text-carried graphic formats in any obvious way.  (It is even weirder, to me, that there is apparently no way to have SVG in-line in any <draw:frame> child, unless I missed it.  So the only rational way to create an SVG image using <draw:image> is by reference to a separate package file with MIME type image/svg and usually extension .svg or svgz.)  It would be an obvious thing to have a <draw:svg> element as an optional child of a <draw:frame>.  The SVG 1.1 specification considers such things under backwards compatibility, <http://www.w3.org/TR/2003/REC-SVG11-20030114/backward.html>, and that would be an useful ODF-Next provision.

> ODF CD05-1 10.4.4 <draw:image> use of <office:binary-data> unimplementable
> --------------------------------------------------------------------------
>
>                 Key: OFFICE-3465
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3465
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Graphics, Part 1 (Schema)
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>            Assignee: Patrick Durusau
>            Priority: Blocker
>             Fix For: ODF 1.2 CD 06
>
>
> See similar issue OFFICE-3463
> In 10.4.4, the image (however obtained) is apparently parked in the <office:binary-data> and the only allowed attribute on <draw:image> is the <draw:filter-name>.  (There can be no xlink:href and the defaults for the other xlink attributes are apparently not relevant.)
> All that 10.4.5 <office:binary-data> provides base64binary of the image, but we are given no clue what the represented image format is. 
> Although there is a "should" about [SVG] and [PNG] but no indication how to tell what the <office:binary-data> represents (and if this case is relevant to [SVG], but if not, how is the SVG included in the element, or is that not provided for?)
> It is unclear how there is a choice to represent the image any other way than in binary data, unless the alternative is always with xlink:href and it is not permitted to cache the retrieved image in the <draw:image> element (because it would then not be refreshable).
> This is seriously underspecified as well as not being interoperably implementable from the information provided.
> Although ODF 1.1:9.3.2 is not much more specific.  There, the XLink information is described as not necessary when the <office:binary-data> is present, but it is not described as forbidden.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira