OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: OpenDocument-v1.2-draft7-7 - Graphics chapters


On 28.09.08 14:25, patrick@durusau.net wrote:
> Greetings!
> Like the pilot in Star Wars kept saying, "...almost there." ;-)
> The text is starting to smooth out enough that with the exceptions of
> chapters 3, 6, 15 and 16 that it would be useful to start getting some
> commentary on the text. I have introduced in this version both Ed. Note and
> Future Note styles to separate out issues we probably need to resolve this
> time and those that may be able to wait to next time.

I have asked Christian Lippka from our graphics team and a few other 
colleagues for comments. Below are Christian's comments regarding the 
graphics, animation and presentation chapters. More comments will follow.

Best regards



9. Graphics


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



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


Regarding the editors note, it is true that <draw:object> and 
<draw:ole-object> do
not support transformation.

---- &

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 
Remark: 9.4.9 has a correct description about the transformation. This 
should also be used
for and


The first "Note:" section only repeats what is already set above.



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 



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

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.


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.


Again as in this description is wrong. The <anim:seq> element is 
a general purpose sequential container.
This section should be removed.



This chapter makes no sense. Only <presentation:event-listener> should 
be in this chapter.

<anim:animateTransform> must be moved to the "14.2.1 General" section.

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

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.


15.7 <table:table-templates>


The assumption is correct.



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.


15.27 Enhanced Graphic Style Elements


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.



Same as above.


15.28. and 15.29. maybe are better placed in a section about 
presentation documents?



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



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.



Regarding to the editors note: horizontal and vertical can be used 
together but also make sense if only one is used.



We should remove the trailing ':'



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.


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.



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.



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



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.

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]