[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: More on graphics response
Greetings! More comments on the responses to the editorial notes on the graphics material: draw:start-glue-point We currently say: > The |draw:start-glue-point| attribute identifies the glue point in a > shape where a connector starts by its number. See 9.3.16. Glue point > numbers are defined by the |draw:id| attributes of the glue point > elements |<draw:glue-point>|. See 18.194. > > When a connector is connected to a shape, a glue point is selected by > the user or the application and its identifier recorded in this > attribute of the glue point. If the connector is not connected to a > shape, this attribute is ignored. > My comment and the response: > Ed. Note I am uncertain about the following language: If a start of a > connector is connected to a shape, either the user or the application > chooses the glue point. All connectors to a shape have a value for > this attribute. If the start of the connector is not connected to a > shape, this attribute is ignored. > > CL: If the user just connects to a shape but does not select a glue > point, than the application can connect the connector to the glue > point that would create the visually pleasant path to the destination. > In most cases this would be the nearest glue point to the destination. > After reading again I would suggest the following: ****** The |draw:start-glue-point| attribute identifies the glue point in a shape where a connector starts by its number. Glue point numbers are defined by the |draw:id| (18.194) attributes of the glue point elements |<draw:glue-point>|. If a connector is not connected to a shape, the draw:start-glue-point attribute is ignored. ****** New question: When we say: "When a connector is connected to a shape, a glue point is selected by the user or the application and its identifier recorded in this attribute of the glue point.", do we mean to require that either the user or the application chooses a glue point? If it helps, note that in prior versions we said: "If this attribute is not set and the start of the connector is connected to a shape, the application may choose the glue point." That implies to me that it is possible to have a connector that is connected to a shape that does not have a value for its draw:start-glue-point attribute. Do we need to add a sentence that says: "A glue point should be chosen by a user or the application when a connector is connected to a shape." ???? Comments/suggestions???? ************************************************************* draw:text-areas We say: > The |draw:text-areas| attribute specifies a list of text areas. The > text area is used to position and align the text. If no text area is > specified, the area of the shape itself is used. If a second text area > is available it is used for vertical text. > > An area consists of four parameters: > > The first parameter specifies the left side of a text area. > > The second parameter specifies the top side of a text area. > > The third parameter specifies the right side of a text area. > > The fourth parameter specifies the bottom side of a text area. > > A parameter can also have one of the following enhancements: > > * > > A “?” is used to mark the beginning of a formula name. The > result of the element's |draw:formula| attribute is used as > parameter value. > > * > > If “$” precedes a integer value, the value is an index to a > |draw:modifiers| attribute. The corresponding modifier value is > used as parameter value. > My comment and the response: > > * > > > Ed. Note As defined, the attribute is inconsistent and incomplete. It > starts by saying we define a list of text areas. Then it says what > happens if a second text area is present. Then we define how to define > a text area. As a string? So, we don't have a list, or at least no > mechanism for one, possibly assume up to two text areas, and don't > define what values define a text area. > > textareas::= textareasequence? > textareasequence ::= textarea ( ' ' textareasequence )* > textarea::= position ' '+ position ' '+ position ' '+ position > position::= formula | modifier | number > formula::= '?' name > modifier::= '$' integer > number::= sign? float | sign? integer > float::= fractional exponent? | integer exponent > fractional::= integer? '.' integer | integer '.' > exponent::= ( 'e' | 'E' ) sign? integer > sign::= '+'| '-' > integer::= [0-9]+ > name ::= [^ ]+ > > If text in a shape is drawn and there is no draw:text-areas element, > then entire area of the shape is used. If the draw:text-areas element > is available, then with one exception the first text area is used. And > this is the exception, if the text is verical and if a second text > area is available, the second text area is used. > OK, let me ask in a different way: This attribute appears on the <draw:enhanced-geometry> element. And, by defining sets of position values, I can define at least two text areas for a shape. First question: Can I have more than two text areas for a single shape? Second question: What is the connection between a second text area and "vertical" text? From the way the current text is worded, it sounds like I can have "vertical" text in one text area, but if I define two text areas, then any "vertical" text is going to be in the second text area. BTW, do we mean: P A T R I C K as "vertical" text? ****************************************************** presentation:object We say: > The |presentation:object| attribute specifies the type of object that > a |<presentation:placeholder>| element stands in the place of. The > value equals the one of the |presentation:class| attribute for > presentation shapes. > My comment and the response: > > Ed. Note: Does this mean that the values of presentation:class act as > a limitation on the values of this attribute? > > CL: Yes > > Actually, after looking at presentation:class, the next question is > whether the restriction of the types for drawing shapes in master > pages is honored here? > > CL: I don't understand the question, can you please rephrase? > In other words, presentation:class defines sixteen classes of shapes (18.395). Four of those sixteen are restricted to drawing shapes that appear in master pages, date-time, footer, header, page-number. If my <presentation:placeholder> element is *not* inside a master page, can its presentation:object attribute have a value of date-time, footer, header, or page-number? *********************************** presentation:path-id We say: > The |presentation:path-id| attribute specifies the shape-id of a > polygon shape. An effect moves along the lines of the specified > polygon. The referenced polygon is not visible during the presentation. > My comment and the response: > > Ed. Note Is this the meaning of “path” in presentation:effect? That > is, it should be path-id? > > CL: it refers to the draw:id of the path shape. Anyway, this is part > of the deprecated animation definition. > Ah, the first sentence should read: "The |presentation:path-id| attribute specifies a polygon shape by the value of its draw:shape-id attribute." Making it clearer (I hope) what is being specified by this attribute. ***************************************** svg:height We say: > See §5.1.2 of [SVG]. > Which generated the following commentary, ;-) > Ed. Note Have I ever mentioned that I like precision in standards? > Referencing into SVG is a nightmare but this is as close as I can get. > Do need to check with graphics to see if we really imply all the > semantics here. > > Ed. Note I have temporarily deleted: “These values are overridden by > the physical size of the linked image resource. They can be used to > get an assumption of the size of the fill image without loading the > image data.” a reference to svg:height and svg:width together. I am > not sure what it means to “override” the values of these attributes. > Rather, an image in a non-SVG format specifies its own size, yes? Why > mix the two together? Moreover, the concluding sentence probably means > an “estimate of the size” but that sounds application specific since > we don't provide a place to record that information. > > CL: if you have the size of the image stored in the document, than you > can start layouting the document before you have finished loading the > image. If the image later turns out to be at a different size, than of > course the size of the image is used. Get yourself a very slow > internet connection and load any html document with lots of images. > You see that the layout will constantly pop around while each image is > loaded one after the other. Other sides may have the image size > already in their html stream so the layout stays constant even if not > all images are loaded yet. > > In html the pixel size in the html stream defines the pixel size of > the image that is drawn on screen. In ODF, “override” means that if > the loaded image has a different size, the size of the image wins. > > Also after putting all svg:height attributes together at this single > place, the above comment is not valid for all elements. Mainly for > those who do not refere to an external image. Also the external image > could be in svg format. Than the svg:width/svg:height from the > external svg image would override the ODF svg:width/svg:height. > OK, would the following language work? "The svg:height attribute can be used with the svg:length attribute to specify the size of a linked image. These values are overridden by the actual size of the linked image." ************************************************ svg:r We say: > The |svg:r| attribue defines the radius of a circle. > > The use of this attribute on the |<draw:area-circle>| and > |<draw:circle>| are defined by §9.3 of [SVG]. > > The use of this attribute on |<svg:radialGradient>| is defined by > §13.2.3 of [SVG]. > My comment and the response: > > Ed. Note I deleted “If this attribute is not set, the position and > size attributes are used to create a circle.” Yes, svg:width and > svg:height are the “size” attributes, svg:x, svg:y are “position” > attributes . What was not stated by the definition was that all of > these were presumed to be in a <draw:circle> element. We should not > rely on context in the standard to make our meaning clear. Since we > are talking about authoring content, why would svg:r ever be missing? > > Ed. Note Yes, this occurs in the 2nd edition of 1.0 as well. > > CL: svg:r would be missed by authoring content if the > author/application prefers to define circles and ellipses with their > bounding box. > OK, but note that svg:x, svg:y, svg:height, svg:width are attributes only on <draw:circle>. They do not appear to be attributes on <draw:area-circle>. If that is correct, I am tempted to suggest a note to be added to the current text that: "Note: If a <draw:circle> element does not have a value for the svg:r attribute, then its svg:x, svg:y, svg:height, and svg:width attributes can be used to create a circle." ************************************************** svg:y We say: > See §5.1.2 of [SVG]. > My comment and the response: > > Ed. Note Interesting that for glue points that we accept length as a > measure and as a percentage, which appears to be excluded elsewhere. > Does that affect the need for the following: “The svg:x and svg:y > attributes specify the position of a glue point. The coordinates are > either percentage values relative to the center of a drawing object > or, if the draw:align attribute is also specified, absolute distance > values relative to the edge specified with the draw:align attribute.”? > > CL: the usage of the svg:y/svg:x attribute depends on the context. > Hard to discuss this on a level where all usages of these attributes > are mixed together. In short, for glue points, the position is not > absolute, it is either relative to an edge of the shape or to its > size. But this is only true for glue points. For shape positions, this > is always absolute to the top-left edge of the page. For other usages > of this attribute, it may be different, f.e. Chart:subtitle. > One of the reasons for putting all the attributes together is to make us enumerate the cases where they are applied differently. Such that the reader is made aware of the differing rules by context. Otherwise they could assume, incorrectly, that any given attribute always has the same semantic throughout. Thus we could insert additional text to say: "The svg:y and svg:x attributes specifies the position of a glue point. The coordinates are either percentage values relative to the drawing objects center or, if the draw:align attribute is also specified, absolute distance values relative to the edge specified with the draw:align attribute." Note that as far as the positioning of shapes, I was unable to find a reference to "absolute to the top-left edge of the page." It may be implied by the language: "The position attributes svg:x and svg:y specify the x and y coordinates of the start position of the drawing shape.", but I think we will need to be more specific than that. Besides chart:subtitle, are there other cases that should be mentioned? ************************************************ xml:id We say (in part, I didn't copy the element list): > The |xml:id| attribute is standardized by the W3C [XML-ID] and gives > an element an unique identification in its XML file. It is designed to > work as an anchor to create references upon its element. > Michael's comment and the response: > Ed. Note: (Michael) Frome the many child elements that <draw:frame> > has, the metadata proposal did only add an xml:id to <draw:image>. > Since having an xml:id there but not for <draw:object> etc. appears to > be inconsitent, I've added xml:id to all of the <draw:frame> child > elements that define content. At the same time, I did not add > <draw:frame>, which had already an xml:id, to above list, because > requiring that an xml:id attribute should be preserved for > <draw:frame> and any of its child elements seems to be superflous. > > CL: we had the same discussion for svg:title/svg:description. Since > per definition all elements inside a frame should be different > representations of the same content, it would be redundant to give > them different meta data. So meta data should only be assigned to the > frame itself in my opinion. > Perhaps, perhaps not. Different representations of the same content could well have different meta data. For example, I might have authored a file in ODF but Svante created a filter and transformed it into OOXML and put my original and his transformation into a single frame as alternative representations of the same content. Shouldn't it be possible to have different metadata on each representation? ************************************* dr3d:texture-mode We say: > The |dr3d:texture-mode| attribute specifies how the texture is > modulated. The permitted values are: |blend|, |modulate|, or |replace|. > > property-dr3d:texture-mode > > The |dr3d:texture-mode| attribute may be used with the following > element: |<style:graphic-properties>| 16.13. > My comment and the response: > > Ed. Note We don't define the meanings of these values. > > CL: They are known to people who are using texture mapping. > Sorry, that doesn't work when defining a standard. And, if they are known, why not include them? *************************************** draw:shrink-to-fit We say: > The attribute |draw:shrink-to-fit| specifies whether the text content > of a drawing object, if necessary, gets shrunk to fit into the drawing > object. Shrinking means that the drawing object's font size is > decreased, so that the complete text fits into the drawing object. > This attribute has no effect on drawing objects where the text content > fits already into the drawing objects. > My comment and the response: > > *Ed. Note:* While integrating this proposal into the specification > I've notices that we have already a style:shrink-to-fit attribute for > table cells. For that reason I suggest that we rename the > draw:shrink-to-fit attribute to "style:shrink-to-fit". > > CL: Then we have one attribute that again behaves completely different > when used in another context. Shrink-to-fit for a table cell means > something different than shrink-to-fit for a shape. > In what way is draw:shrink-to-fit different from style:shrink-to-fit? In both cases there is text that is being shrunk to fit into a cell or shape. In both cases the font size is reduced until the text fits. How is that different in these two cases? BTW, this is probably a legitimate future issue rather than something we need to change for ODF 1.2. *************************************** Christian also posted a note on: anim:audio-level We say: > The |anim:audio-level| attribute specifies the volume during playback. > Its value is a number in the range 0 (inaudible) to 1 (the system volume). > My comment and the response: > > Ed. Note System volume is undefined and that in the schema the > datatype is double. > > CL: System volume means that you can't define the sound to be louder > than what the user set as the loudest volume on his system. So '1' is > the maximum volume allowed on that system and 0.5 would be half of that. > OK, so would: "The |anim:audio-level| attribute specifies the volume level during playback. Its value is a number in the range 0 (inaudible) to 1 (the maximum system volume)." do the trick? Hope everyone is having a great day! 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]