[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=22216#action_22216 ] 

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

+1 with Andreas here.

  1. There are two kinds of cases for <draw:image>.  

1.1 First, the primary representations (those given first) for <draw:frame> need not be provided by <draw:image> 

1.2 Secondly, the primary representation may be delivered by a <draw:image>, presumably one provided by the producer on behalf of an user.

  2. In either case there may be multiple <draw:image> elements with some preference indicated by their order of occurrence among themselves and any other children of the <draw:frame>.

  3. In all of these cases, what an user might supply for an image, and how that is supplied, and whether that is supplied, need dictate how the image is represented in a <draw:image> element.  (I assume that is what those implementation-dependent filter names are about, in part.)

  4. Coming back to the specific case of  <office:binary-data> children of <draw:image> elements, my sense is that the most we have been able to tease out is that (1) the image format is one that shall be discoverable by inspection of the binary data and (2) no help is being given to the consumer on what ones consumers shall distinguish as part of supporting these occurrences of <office:binary-data>.

5. I recommend that we at least be specific about (4) and it would be great if we would indicate a preference of PNG for raster images of graphics and JPG for raster images of images involving continuous tones, such as photographs.  (The SVG option does not apply to <office:binary-data>, although there are vector-graphic formats that are encoded in binary data.)





> 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, Needs Discussion, 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