Re: [office] OpenDocument-v1.2-draft7-7 - Graphics chapters

[Patrick Durusau <patrick@durusau.net>]

Christian,

Catching up on replying to all the editing posts! Sorry for the delay.

Christian Lippka - Sun Microsystems Gmbh - Hamburg wrote:
> Hi Patrick,
>
> please find my comments inline
>
> Patrick Durusau wrote:
>
> [...]
>>> ---
>>>
>>> 9.4.10
>>>
>>> The part "Text boxes don't support contours as described in section 
>>> 9.4.10 and alternative
>>> texts such as <svg:title> 9.3.17 and <svg:desc> 9.3.18." is 
>>> mis-leading. As <draw:image>
>>> and <draw:object>, the element <draw:text-box> describes content 
>>> inside <draw:frame>. The
>>> <draw:frame> itself can have <svg:title> and <svg:desc> elements. It 
>>> can have multiple
>>> representations of the same content. Since the content should be the 
>>> same (f.e. one is
>>> a textual representation, another is an image of the text), there is 
>>> only need for one
>>> title and description here.
>>>
>>> This part should be removed. Maybe the <draw:frame> should have a 
>>> section where the
>>> above is explained
>>>
>> Removed the text.
>>
>> The following text now appears in a general section for frames:
>>
>> *****
>>
>> A frame is a container for enhanced content like text boxes, images 
>> or objects. A frame may contain multiple renditions of content. An 
>> application may choose the representation that it supports best.
>>
>> Multiple representations may share |<svg:desc>| and |<svg:title>| 
>> elements such that those are used for each representation.
>>
>> In general, applications do not render more than one of the content 
>> elements contained in a frame. The order of content elements dictates 
>> the document author's preference for rendering, with the first child 
>> being the most preferred. This means that applications should render 
>> the first child element that it supports. A frame must contain at 
>> least one content element. The inclusion of multiple content elements 
>> is optional. Application may preserve the content elements they don't 
>> render.
>>
>> Within text documents, frames are also used to position content 
>> outside the default text flow of a document.
>> *****
>>
>> I am not happy with the third paragraph but am moving on to finish 
>> more comments. We seem to go from child element to content element 
>> and back.
> Maybe give a sentence like "Each child element of a frame is a 
> different representation of the same content" and then continue 
> talking only about child elements?-
Done.
>>> 9.4.5.3
>>>
>>> Regarding the editors note, it is true that <draw:object> and 
>>> <draw:ole-object> do
>>> not support transformation.
>>>
>> OK, but do I need to say that here?
>>
>> If I don't say anything about transformation for <draw:object> or 
>> <draw:ole-object> what impact does that have?
>>
>> Neither one has the draw:transform attribute so it seems quite 
>> natural that it doesn't apply to them.
>>
>> Or am I missing something real subtle here?
>>
>> My suggestion (in the draft I am writing now) is to simply omit any 
>> mention of the transformation issue.
> I agree, I just wanted to comment on the note. I don't think that this 
> must be mentioned.
Done.
>
>> Question: When we say:
>>
>>> The xlink:href attribute of this element references the sub package 
>>> of the object. The object is contained within this sub page exactly 
>>> as it would as it is a document of its own.
>>>
>> Should "....within this sub page exactly as it would as if..."
>>
>> Read: "....within this sub package exactly as it would as if..."
>>
>> sub page -> sub package, Yes?
> Yes
>
> [...]
>
Done.
>>> 9.7
>>>
>>> Regarding the editors note, it is true that the first paragraph is 
>>> mis-leading. Also the whole of
>>> 9.7 mixes two different features. The first paragraph sounds like 
>>> shapes in a presentation are
>>> presenation shapes. Corret would be that shapes in a presentation 
>>> can be presentation shapes, but
>>> only a subset (<draw:frame> and <draw:page-thumbnail>) and only if 
>>> they are part of the presentation layout.
>>>
>>> Furthermore, some shapes in a presentation can have a style from a 
>>> presentation family instead from
>>> the graphic family. This is true for all presentation shapes (again, 
>>> only <draw:frame> and <draw:page-thumbnail>
>>> that also have the "presentation:class" attribute and therefore are 
>>> part of the presentation layout.
>>>
>>> This is also true for regular shapes that where placed on a master 
>>> page which are usually assigned a presentation
>>> background style. They do not have the "presentation:class" 
>>> attribute set and can only be identified as
>>> having the "presentation:style-name" attribute instead of the 
>>> "draw:style-name" attribute.
>>>
>>> The later is kind of an application specific feature of 
>>> OpenOffice.org impress.
>>>
>> OK, I am assuming that we cover this more specifically under 
>> particular elements? That is we say all of these uses/restrictions 
>> elsewhere.
>>
>> So, do we simply kill 9.7?
>>
>> Is there any supplemental text I can put elsewhere so we can kill it?
> Actually I would not kill 9.7 as this feature should be documented 
> somewhere and this place seems like a good
> candidate. I would not recommend moving the explanation to the 
> different elements that can be presentation shapes.
> There was another comment on the oasis tc list from Doug Mahugh 
> regarding presentation shapes. Maybe we can
> start a discussion to come up with a more clear explanation.
> If not maybe we can replace the first sentence of 9.7 with
> "Presentation shapes are shapes on a draw page that are part of a 
> presentation page layout [see 15.28]"
> Then 9.7 will not be mis-leading anymore. But still a better 
> explanation would be nice to have.
Done. Left Ed. Note for better explanation.
>
>>> 9.9.1
>>>
>>> About the future note: The <presentation:animations> from chapter 
>>> 9.8 has nothing to do with the chapter 9.9 smil animations.
>>> 9.8 describes the old animation system. Both chapters should be kept 
>>> separate and it should be clear that they can not be mixed
>>> in a document
>> OK, so at some point in the future we can deprecate 9.8 in favor of 9.9?
> Yes
>>
>> When you say, "cannot be mixed" you mean at the element/attribute 
>> level? A document could have both. Yes?
> Yes, a document can have both but they are defined seperatly.
Done.
>
>>> Also the removal of "Recommended Usage Of SMIL" is a bug. This 
>>> chapter is very importent to understand that
>>> there are limitations. SMIL is a general purpose animation language 
>>> that is far to complex for a general
>>> office application if all features are directly provided for the 
>>> user. Therefore the removed chapter described
>>> how the SMIL subset should be structured in a presentation document. 
>>> This must be re introduced.
>>>
>> I disagree.
>>
>> Mostly because there are any number of things that can be done with 
>> SMIL, including the one that is illustrated.
>>
>> The subset of SMIL that is "far too complex for a general office 
>> application" is represented by the SMIL elements and attributes 
>> chosen for inclusion in ODF. What more need we say?
> I do not understand this sentence.
>>
>> I freely grant that illustrating the use of SMIL is important and 
>> that is why I have inserted all the hooks so that we can add even 
>> longer illustrations and example material to an enhanced version of 
>> the standard. Think of it as the ODF standard + Examples that 
>> Interest Me editions. I don't have a lot of interest drawing objects 
>> (sorry drawing team) but do have a fairly deep interest in text 
>> annotations. So I might have a version of the standard that is 
>> replete with extensive examples of text annotations, etc. While the 
>> drawing team members prefer one with just the minimum on annotations 
>> and extensive examples on drawing objects. Up to and including 
>> implementation code for that material if one was giving the standard 
>> to an implementer.
>>
>> Sorry, delivery of effective standards for particular users is a 
>> hobby horse of mine.
> The removed usage of SMIL is not a recommendation for a 'particular 
> user', it is a vital documentation for people that want to create 
> applications that work with odf presentation documents.
> Element and attribute wise we do not use only a 'subset' of SMIL, we 
> nearly use all of it. So on a syntax level the SMIL elements in ODF 
> are SMIL. But we also must define a semantic
> level how they should be used. I would agree to your disagree if we 
> define that the "ODF standard" specification is only for humans to 
> read ODF documents and the "ODF standard + Examples that Interest Me 
> editions"
> is for people who actually create applications that work with ODF. But 
> I think this is not the case.
>
OK, but I made it an appendix since it isn't defining any elements or 
attributes but giving advice on their usage.
>>> 9.9.1.1
>>>
>>> The new description of the <anim:par> element is wrong. An 
>>> <anim:par> element is not only the root
>>> animation element but it is a general purpose parallel container for 
>>> animations as described in the wrongly
>>> removed chapter. This section should be removed.
>>>
>> Ah, what you mean is that the information about this element that was 
>> in the SMIL usage chapter, odd place for normative element 
>> information, should be replaced here. OK.
>>
>> I have recast it to read:
>>
>> *****
>>
>> |The <anim:par>| element is a general container for animations and 
>> may contain <anim:par> elements that contain animations that are 
>> executed at the same time. An |<anim:par>| element should contain one 
>> |<anim:seq>| element which is the main sequence for shape effects and 
>> zero or more |<anim:seq>| elements that define interactive sequences 
>> for shapes that contain animation interactions. The animation 
>> elements are executed after the |<draw:page>| 9.2.4 has executed its 
>> initial transition.
>>
>> *****
> No, this is a confusion caused by the removal of the "Recommended 
> Usage Of SMIL" chapter. It is just confusing to try to define it for 
> <anim:par> and <anim:seq>. Please have
> a look at the corresponding documentation in SMIL. An <anim:par> is no 
> more and no less just a container which child nodes are started at the 
> same time, where a <anim:seq> container is a container where the child 
> nodes start in a sequential fashion.
> I would not try to document the overall structure in the <anim:par> 
> and <anim:seq> elements, it only adds more confusion.
>
> If you disagree that the information in "Recommended Usage Of SMIL" 
> should be documented at all, why do you try to document it at element 
> level?
Good question! ;-)

Even after adding the advice on the use of these elements I fail to see 
what is confusing about actually documenting their structure? Either 
that structure can be stated or not. However, I have taken your advice 
and simply defined <anim:par> as a container of child nodes that share a 
common starting point, etc. Same for <anim:seq>.

>
>> Question: I take it you are ok with the removal of "slide" and its 
>> replacement with draw:page? See the editors note.
> Yes
>>> -----
>>>
>>> 9.9.1.2
>>>
>>> Again as in 9.9.1.1 this description is wrong. The <anim:seq> 
>>> element is a general purpose sequential container.
>>> This section should be removed.
>>>
>> Ah, what you mean is that the information about this element that was 
>> in the SMIL usage chapter, odd place for normative element 
>> information, should be replaced here. OK.
>>
>> I recast this to read:
>>
>> *****
>>
>> The |<anim:seq>| element is a general purpose container which 
>> contains the effects that should start after the |<draw:page>| 9.2.4 
>> has executed its initial transition.
> No it is not, this is plain wrong. See above for <anim:par>. Yes, an 
> <anim:seq> is the root element to put SMIL animation information 
> inside a <draw:page>, but that should not be the way how it is defined.
> That is like saying "a <text:p> element is a general purpose text 
> container which contains the text in a writer document".
See above.
>
>> This is a sequential container, that is its child nodes are executed 
>> one after each other. If a child node's |smil:begin| attribute has 
>> the value |indefinite|, then execution is delayed until the user 
>> advances the sequence by a mouse or key interaction.
>>
>> The first level of child nodes in the main sequence should be 
>> |<anim:par>| elements that group animation elements that are started 
>> with the same user interaction. The second level of child nodes 
>> should be |<anim:par>| elements that group animations elements that 
>> start at the same time. The third level of child nodes should be 
>> |<anim:par>| elements that group the animation elements for a single 
>> effect.
>>
>> *****
>>
>> Question: Are there more than 3 levels of nodes? (see the editor's note)
> This was all very well documented in the "Recommended Usage Of SMIL" 
> chapter.
>
> [...]
Well, in my view it gives suggested usage, not the same thing as 
documentation. However, I have entered the edits as indicated.
>>> 15.6.5 <presentation:notes>
>>>
>>> Regarding the editors note: This is not a limitation of OpenOffice. 
>>> In fact OOo can put all kinds of shapes on a
>>> notes page. This seems to be a limitation that enables application 
>>> to better present notes to the user in a format
>>> that is not a "page". For example as a tooltip or a text frame under 
>>> the current page.
>>>
>> Sorry, I wasn't clear. In other words, can I simply kill that 
>> statement? What an application does or doesn't display a user, so 
>> long as it honors the format, really isn't our concern. Yes?
> Yes, just remove the editors note.
Done.
>>> 15.8.
>>>
>>> The background of the table is the rectangular area behaind the 
>>> table. F.e. it is the area that is visible if a cell
>>> has a transparent filling. Also if you put an image on the 
>>> background and make the cells transparent the image would
>>> stretch over the whole table and would not be repeated for each cell.
>>>
>> A little awkward but how does this sound as a rough cut:
>>
>> "The |<table:background>| element specifies the table style provides 
>> a background to a table that is visible if all or part of the table 
>> is transparent."
> Yes
Done.
>>> 15.27 Enhanced Graphic Style Elements
>>>
>>> 15.27.1
>>>
>>> The <draw:gradient> can only be defined in the <office:styles> 
>>> section. It can be 'referenced' by name from any
>>> style in the <office:styles> and <office:automatic-styles> section.
>>>
>> OK, you are as bad as I am. ;-) Too much information! So, gradients 
>> are available in automatic styles and so:
>>
>> "The element |<draw:gradient>| defines a gradient for filling a 
>> drawing object."
>>
>> Is all I need say. Delete the last sentence "Gradients are not 
>> available as automatic styles." and the Ed. Note:
> Yes
Done.
>>> 15.28. and 15.29. maybe are better placed in a section about 
>>> presentation documents?
>>>
>> Possibly, possibly. What else would go there as far as elements?
>
Need to come back to this, marked as an Ed. Note.
>>> ---
>>>
>>> 18.203.
>>>
>>> -50% blue is undefined. Yes the should be positive between 0 and 
>>> 100%. Better would be a value between 0 and 1 which
>>> is more like what other formats (f.e. svg) would do.
>>>
>> OK, but is that a non-backwards compatible change?
> Yes, this should be discussed on the list.
Ed. Note in place. Will raise on the list.
>>> 18.598
>>>
>>> We should remove the trailing ':'
>>>
>> Done in current version but note that we still need definitions for 
>> these effects. I could detect little relationship between the name 
>> and what effect I saw but that may just be me. Thinking that with 
>> definitions that applications might come closer to offering a common 
>> experience.
> Well they do not describe the complete effect, only the direction. But 
> anyway we maybe should not spend much time as this is only part of the 
> deprecated animation system. If you use OOo 2.0 or newer you will not 
> be able to create documents that uses them.
> Only Lotus Symphony still does...
>
OK, but we haven't deprecated it yet, have we?
>>> 18.609
>>>
>>> Regarding to the editors note: Why does it makes no sense? F.e. you 
>>> can have a sound in the time line that is
>>> an effect the user added. But you could also have a shape effect 
>>> that includes a sound. For the user it makes
>>> no sense to see an additional sound effect for the shape effect he 
>>> created. He expects the sound to be a property
>>> of the shape effect he created. Even if technically they are two 
>>> independent nodes in the SMIL animation tree.
>>> Removing this explanations means we do not have to document this 
>>> attribute at all because just from the name it
>>> is not obvious why this attribute is needed. I think the removed 
>>> description  is understandable and important for people that have to 
>>> implement a simple user interface for animations.
>>>
>> Well, it seems like it is enabling specific application behavior 
>> without ever say what that behavior may be.
>>
>> Take your example, say I have a sound on a time line. And I have a 
>> shape effect that includes a sound.
>>
>> Are we assuming the same sound?
>>
>> What I am trying to understand is which element gets the 
>> presentation:master-element attribute and under what conditions does 
>> that signal an application to only show one sound? Seems to me there 
>> is still something missing.
> Ok now I think I see the misunderstanding. If we have one effect with 
> a sound effect played, than there is only one sound effect. But in the 
> SMIL hierarchy (which is rather complex) it is not obvious that the 
> sound element is
> actually part of the effect. F.e. it is not contained inside the 
> effect <anim:par> container and there is no way to determine if the 
> user just added a sound that (by chance) starts at the same time as 
> the effect starts.
> For correct playback of the animation seqeuence, the attribute 
> "presentation:master-element" is not needed at all. But for the user 
> interface to meet the expectations from the user, it is needed.
OK, I am trusting you on this one. ;-)

Replaced the prose.
>>> 18.621, 18.622 and 18.623
>>>
>>> Both attributes can be used for applications to keep track which 
>>> user interface animation created these smil elements.
>>> In theorie an infinite number of effects can be created by combining 
>>> the defined SMIL animations. ODF does not define
>>> which ones make sense, so applications can offer different subsets 
>>> of effects that the user can add to his documents.
>>> Different applications must be able to play all kinds of effects but 
>>> may mark effects from user applications as
>>> "user defined" effects while giving descriptive names to effects 
>>> they know.
>> OK, so presentation:preset-class is actually a type? Such that 
>> presentation:preset-sub-type specifies a subtype of a type?
>>
>> And where are these presets defined? The ones that exist by combining 
>> defined SMIL animations?
>>
>> Noting that "entrance" only appear here. :-( Rather hard to match up 
>> application abilities if it is completely undefined.
> No it is actually a feature. Regardless about knowing of 
> "presentation:preset-class" and "presentation:preset-sub-type", all 
> applications
> can play all effects from other applications. But each application can 
> put in their own set of effects that user can assign. Maybe an
> application can even decide to let the user create such effects from 
> scratch. OOo 2.x currently has > 200 such effects. Should we
> really document each one of them? Think of it as a kind of a clipboard 
> library. Yes we have a path shape, but should we document
> all the Elephants, Chairs or Flower clips you can draw with it?
Removed the ed. notes. Do note that OOXML was asked to define the 
various border art definitions. But then they already existed. That may 
make this different.
>>> 18.633.
>>>
>>> Agreed that it is a bit hard to understand, but the usage of master 
>>> page and presentation styles makes sense.
>>> Maybe there should be a chapter explaining the concepts behind it? 
>>> Anyway, it is nothing you could describe
>>> with just a few sentence and out of context for specific attributes.
>>>
>> Err, why don't you pen a few lines about the explanation and let's 
>> see what we can do? I am sure there is some logic behind it but it 
>> isn't apparent just yet.
> Ok. First think to know is that a master page is not only a 
> 'background picture'. It also contains the position for the layout 
> ("title area" and "outline area"),
> it also comes with a set of styles ( "title style", "outline style", 
> e.t.c). The idea is that if you exchange the master page of a 
> presentation, it also changes the
> formating of (some) shapes on the draw pages. And not only position 
> but also style. Therefore some shapes on the draw pages must be 
> 'special' shapes.
> They are the once that are part of a presentation page layout. For 
> example the "Title, Outline" layout has a title shape and an outline 
> shape. Both are
> <draw:frame> with a text box inside. To know that they are special 
> shapes they have the presentation:class attribute which tells the 
> application if this is
> the shape that is the title of a draw:page or the outline or a graphic 
> that is part of the presentation page layout. Since these shapes 
> should be formated
> according to the master page that this their draw:page is assigned to, 
> they also have a presentation style set and not a draw style.
>
> The main difference between presentation styles and graphic styles are
>
> 1. There can be any number of graphic styles and they are used 
> document wide.
> 2. Each master page come with a fixed set of presentation styles that 
> are used on presentation shapes on draw:pages that uses this master page
>
OK, left it as it was.

Hope you are looking forward to a great weekend!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)