[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OpenDocument-v1.2-draft7-7 - Graphics chapters
Hi, 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 Michael --- 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 --- 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 --- 9.4.5.3 Regarding the editors note, it is true that <draw:object> and <draw:ole-object> do not support transformation. ---- 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 --- 9.4.12.5 The first "Note:" section only repeats what is already set above. --- 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. --- 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 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. ---- 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. ----- 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. ----- 9.9.2 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> 15.7.7 The assumption is correct. --- 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. ---- 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. --- 15.27.5 Same as above. --- 15.28. and 15.29. maybe are better placed in a section about presentation documents? --- 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. ---- 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. ---- 18.330 Regarding to the editors note: horizontal and vertical can be used together but also make sense if only one is used. ---- 18.598 We should remove the trailing ':' ---- 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. ---- 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. ---- 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. --- 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). --- 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. -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS 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]