Input for ODF plugfest/TC call

[Thorsten Zachmann]

On Tuesday, April 24, 2012 23:57:54 Friedrich W. H. Kossebau wrote:
> Yes, e.g. the above OFFICE-3750 is for me. But there has never been any
> reply  to an email saying
>          "Thanks for your input, please track how we deal with the issue at
>           http://tools.oasis-open.org/issues/browse/YOUR_ISSUE"
> . Instead there is silence from the TC side. Just the monthly reminder,
> which  feels like the not-shut-down automatic announcement system on a
> dead train station where you walk lonely on a platform, which is now and
> then reminding people to take care of one's luggage</prose>.

Lets see if we can make this possible in the TC

> > > D) Handling of custom shapes just a hack ATM?
> > >
> > > 
> > >
> > > The current storage looks like a hack to me, it is no-where specified
> > > in the spec, is it? And it does not survive a round-trip to a ODF
> > > consumer/producer which does not support that custom shape. Which I
> > > consider a fail :(
> >
> > 
> >
> > This is well defined but as Jos already said some implementations have
> > bugs that breaks this. However it seems the situation is improving
> 
> I was totally imprecise about what I actually meant, sorry. Next try:
> 
> For custom embedded objects at least to me the ODF 1.2 spec is not really 
> clear how to properly store them, especially together with a fallback image
> in  case the consumer does not have a handler for the original format of
> the object.
> 
> "10.4.6.1 General" talks about two types, object with an OpenDocument 
> representation and objects without. The first are to be referenced by a 
> <draw:object> tag and the latter?
> "10.4.6.3 <draw:object-ole>" says: "The <draw:object-ole> element
> represents  objects that do not have an OpenDocument representation.".
> 
> My question 1: All, or just those with OLE properties (which is platform 
> dependent, no?)? And if the latter, how to store non-OLE objects?
> 
> At least the mapshape code, which I used as template for the barcode shape
> I  did, stored its data in a custom element container, without wrapping it
> in <draw:object-ole> or something else.
> 
> Same with the fallback image/object: I learned from someone and the
> mapshape  code, that the fallback image should be placed behind the actual
> content token in the <draw:frame>, as any ODF consumer which does not
> recognize the content token will just skip that and read the fallback
> image as content for the <draw:frame>, while ODF consumers which do
> recognize it expect only one token (as defined by the spec) in the
> <draw:frame> and skip the fallback image token.
> 
> But I cannot find that approach being described in the spec.
> My question 2:  Did I just miss it? Or does that need to be specified?

Seems you missed it. Here the part of the spec that I can read it from.

10.4 Frames
10.4.1 General
A frame is a container for enhanced content like text boxes, images or 
objects. A frame may
contain multiple renditions of content. A consumer may choose the 
representation that it supports
best.
Multiple representations may share <svg:desc> and <svg:title> elements.
Each child element of a frame is a different representation of the same 
content. The order of
content elements reflects the document author's preference for rendering, with 
the first child
element being preferred. That means that consumers should render the first 
child element that
they support. A frame may contain multiple content elements, but shall contain 
at least one
content element.

Thorsten