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

[Patrick Durusau <patrick@durusau.net>]

Michael,

The next set in my directory of files of comments. ;-)

Significant questions (see below for details):

1. Do we kill 9.7?

2. 9.9.1 Not mixing types of animation question

3. Recommended Usage of SMIL removal

4. 9.9.1.1 removed "slide" and substituted "draw:page" OK?

5. 9.9.1.2 More than 3 levels of nodes? Where defined?

6. Where to put <presentation:event-listener>? Sections cannot have one 
subsection. Can either promote it or find it another home. Suggestions?

7. 15.6.5 - Do we kill the text in the editor's note?

8. 15.8 - New text on table background

9. 15.27.1 - Review new text.

10. 15.27.5 - Review deleted text

11. 15.28. - 15.29 - Suggested chapter on presentation documents? Comments?

12. 18.203 - Is this non-backwards compatible? I agree with the 
suggestion but advise caution in changing. (this is the issue where we 
allow signed percentages in excess of 100 on colors)

13. 18.609 Questions to clarify the response.

14. 18.621, 18.622 and 18.623 - Note questions on lack of definitions.

15. 18.633 More explanation requested.


Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

<snip>
> ---
>
> 9. Graphics
>
> 9.3.4
>
> Replacing "size attribute" with "svg:height" and "svg:width" in 9.3.5 
> is ok, but than
> this should also be done in 9.3.4
>
Good catch, need to be consistent.
> ---
>
> 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.


> ---
>
> 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.

******

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?

*****
>
> ----
>
> 9.4.6.1 & 9.4.7.1
>
> Applets and Plugins cannot be transformed, not even by using the 
> surrounding <draw:frame> element.
> Therefore the statement "Applets cannot be transformed as described in 
> section 18.392,
> although it is possible to provide a transformation of the surrounding 
> <draw:frame> element."
> is mis-leading. The main reason behind this is that applets (and the 
> same for plugins)
> are system windows and on current operation systems they can not be 
> transformed.
> Remark: 9.4.9 has a correct description about the transformation. This 
> should also be used
> for 9.4.6.1 and 9.4.7.1
>
OK, but I just deleted all of the "cannot be transformed" as they all 
lacked the necessary attribute. If we start describing what an element 
cannot do based on the absence of attributes the text will be quite 
long. ;-)
> ---
>
> 9.4.12.5
>
> The first "Note:" section only repeats what is already set above.
Good catch! Eliminating that sort of thing is the key to writing a good 
standard.
>
> ---
>
> 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?
>
> ---
>
> 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?

When you say, "cannot be mixed" you mean at the element/attribute level? 
A document could have both. Yes?

>
> 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 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.
> ----
>
> 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.

*****

Question: I take it you are ok with the removal of "slide" and its 
replacement with draw:page? See the editors note.
> -----
>
> 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. 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)
> -----
>
> 9.9.2
>
> This chapter makes no sense. Only <presentation:event-listener> should 
> be in this chapter.
>
OK.
> <anim:animateTransform> must be moved to the "14.2.1 General" section.
Done.

And I re-order the element to be in alphabetical sort order.

Just as a general note, if anyone sees material out of sort order let me 
know.
>
> <presentation:header>, <presentation:date-time> and 
> <presentation:footer> are text fields (that are special for 
> presentations).
> They must be moved to the "9.9.7 Presentation Document Content" section.
>
Done.
>
> 14 SMIL Animations
>
> ---
>
> 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?
> ---
>
> 15.7 <table:table-templates>
>
> 15.7.7
>
> The assumption is correct.
>
OK.
> ---
>
> 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."
> ----
>
> 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:

> Gradients are not available as automatic styles.
>
> Ed. Note: I don't understand the last sentence. Do we mean to say that 
> <draw:gradient> elements can't appear in styles? Or only in automatic 
> styles? A gradient by itself is insufficient to be a style so I 
> suspect we meant something else.
>
OK, I deleted the additional text and the note.

> ---
>
> 15.27.5
>
> Same as above.
>
OK, I deleted

"Hatches are not available as automatic styles."
> ---
>
> 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?
> ---
>
> 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?
> ----
>
> 18.276
>
> Regarding to the editors note: only closed subpathes will be filed. A 
> closed subpath is a path which start and end point
> is equal. Applying a fill style on a non closed subpath does not fill 
> it at all.
>
OK, deleted the editor's note.
> ----
>
> 18.330
>
> Regarding to the editors note: horizontal and vertical can be used 
> together but also make sense if only one is used.
>
>
OK, deleted editor's note.
> ----
>
> 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.
> ----
>
> 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.


>
> ----
>
>
> 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.
> ----
>
> 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.
>
> ---
>
> 18.924
>
> The viewBox enables a unit less definition of vector graphics on a 
> device with units (be it pixels, cm, twips or whatever).
> This is also how it is defined in svg. Since this is not only used for 
> <draw:enhanced-geometry> but also for polygons and
> path elements, the initial description is a bit confusing. Please note 
> that a viewBox has nothing to do with an 'image', if
> image is defined as a graphic defined by 'pixels' (f.e. a jpeg).
>
OK. I will make a separate note for later use. Deleted the editor's note.
> ---
>
> 18.931
>
> Yes, for glue points it make sense to have relative positons. We added 
> this explanation on request to the specification
> as it was not clear. So the documentation for the special usage of 
> svg:x and svg:y for clue points also in relation to
> the draw:align attribute should be part of the specification.
>
Ah, yes, since the presence of another attribute affects the semantics, 
it really has to be in.

I put the language back under svg:x and svg:y. Duplicates I know but I 
wanted to get everything in and then we can toss stuff once it is right.

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)