[OASIS Issue Tracker] Issue Comment Edited: (OFFICE-3465) ODFCD05-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=22014#action_22014 ] 

Dennis Hamilton edited comment on OFFICE-3465 at 10/8/10 4:28 PM:
------------------------------------------------------------------

+1 with Andreas.

I agree that there should be a recomendation and perhaps even a minimum that a Consumer shall accept.

The problem with SVG, however, is it has nothing to do with <office:binary-data> and there seems to be even more reluctance to say anything about how xlink:href is used to access an SVG element.

My first effort is to tease out exactly what is intended for this by those who support it, so we at least know what it is.  The best I've managed to elicit is that the <office:binary-data> image format shall be discovered by inspection.  I personally favor a stronger statement that gives the implementers of consumers some fixed set that they shall/should expect to support.  That is independent of the note about when one of a graphic or a raster image is preferable.  I think the note is applicable either way.  The universal statement of preference for SVG is of no added value for photographic images and other use cases.

Now, because we are talking exclusively about <draw:image> here, it may be that it is simply intended for consumers to rely on alternatives in the <draw:frame>.  If so, that is a well-specified (though iffy) situation too.

Even so, I would welcome a statement about what consumers shall be prepared to handle, so that producers of a <draw:frame> for an image has at least one <draw:image> that is so consumable. 

I don't know what to say at the <draw:frame> level that would convey that a producer should always have at least one of the consumer-assured <draw:image> cases when the frame is for an image.

Any suggestions?



      was (Author: orcmid):
    +1 with Andreas.

I agree that there should be a recomendation and perhaps even a minimum that a Consumer shall accept.

The problem with SVG, however, is it has nothing to do with <office:binary-data> and there seems to be even more reluctance to say anything about how xlink:href is used to access an SVG element.

My first effort is to tease out exactly what is intended for this by those who support it, so we at least know what is and is not particularly interoperable.  I favor a stronger statement that gives the implementers of consumers some fixed set that they shall/should expect to support.  

Now, because we are talking exclusively about <draw:image> here, it may be that it is simply intended for consumers to rely on alternatives in the <draw:frame>.  If so, that is a well-specified (though iffy) situation too.

Even so, I would welcome a statement about what consumers shall be prepared to handle, so that producers of a <draw:frame> for an image has at least one <draw:image> that is so consumable.


  
> 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