Re: [office] More on graphics response

[Patrick Durusau <patrick@durusau.net>]

Christian,

Christian Lippka - Sun Microsystems GmbH - Hamburg wrote:
> Hi Patrick & all.
>
> See my comments inline
>
> Patrick Durusau wrote:
>> 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."
> To make this a little more clear. A user can connect a connector to a 
> shape. A user can also select a glue point while doing so, but he does 
> not have to.
> If the user does not select a glue point, than the application will 
> choose the gluepoint that it sees best fit *during rendering the 
> document*. This means
> that the application can change the used glue point on the fly in case 
> the user changes the position of connected shapes later. For example 
> consider
> a shape A and a shape B, A is placed on the slide 'north of' shape B. 
> Imagine if you will that both Shapes have a North and a South glue point.
> Now the user creates a connector from shape A to shape B. Logicaly he 
> would choose the South glue point from shape A and the North glue point
> from shape B, since then the connector can layout in a straight line 
> between these two shapes without the need to layout 'around' them.
> Now the user places shape A south of shape B. If the user had chosen 
> the glue points manually, the connector would now still leave shape A 
> at its South
> glue point and enters shape B at its North glue point, therefore he 
> needs to layout all the way around both shapes to not intersect them. 
> In many cases
> this is not the most pleasant and non optimal layout of a connecter. 
> But if the user did not choose the glue point itself, then the 
> application can now
> switch the glue points so that again the connector is layouted as a 
> straight line between shape A and shape B. To indicate that the glue 
> point is not
> set manually by the user, the glue point id is omitted in this case.
>
> So yes, it is valid to have a connector connect to a shape without 
> having a draw:start-glue-point or draw:end-glue-point attribute.
>
> Hope this clarifies it.
Well....., ;-)

Ok, let me try to say that back to you and see how close/far away I am:

A user can choose a glue point but doesn't have to for a connector.

If the user doesn't choose a glue point, the application does.

But, where the application chooses the glue point, the glue point id is 
omitted.

OK, so at the time of rendering, the layout engine chooses the "best" 
placement of the connector.

Question: How does the application know which shapes are connected if it 
has not glue point ID?

Noting that we define *connector* as follows:

> The |<draw:connector>| element represents a series of lines that are 
> connected to the glue points of two other shapes.
>

And yes, for the history buffs among us, ODF 1.1 says:

> The <draw:connector> element represents a series of lines that are 
> connected to the glue points of two other shapes.

That seems to me to rather clearly define a connector element to include 
its attachment to glue points of two other shapes.
>
>>
>> ******************************************************
>>
>> 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?
> a <presentation:placeholder> element can not be inside a master page, 
> it can only be inside a <style:presentation-page-layout> element.
> But I think I'm getting to the source of your confusion. A 
> <style:presentation-page-layout> is a container that describes one 
> page layout template if you will. It defines what presentation
> shapes are placed at which positions if such a layout is assigned to a 
> slide (but only at the time the user manually assigns it, since after 
> that the user could have removed shapes that are part of the layout).
>
> Since Date-time, footer, header, or page-number are presentation 
> shapes that can only be placed on the master page and that can not be 
> part of a presentation layout, they are not
> available as values for the |presentation:object| attribute.
>
> So the values of the presentation:class attribute act as a limitation 
> in the sense that there are no other values are allowed but then again 
> some values from presentation:class are not
> allowed here.
Ah, ok. I need to think about how to make that explicit.
>>
>> ***********************************
>>
>> 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."
> There is no "svg:length" attribute, what do you mean?
Sorry, svg:width.
>>
>> ************************************************
>>
>> 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."
> Yes. The <draw:area-circle> is part of an image map, which evolved 
> from the htmp image map specification so there are differences in 
> features.
> Not consistent at the first look but then again, the first describe a 
> shape, the later a circular area inside an image map.
>>
>> **************************************************
>>
>> 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.
> If its not already part of the specification, than a "the origin of 
> the coordinate system of a page is its top-left edge" should do the 
> trick.
No, we define a user coordinate system for svg:viewBox and a top-left 
system for cells but not for pages.

Actually, after thinking about it, wouldn't that be the top-left edge of 
a draw:page element? Thinking that gives the ability to arrange shapes 
relative to each other within a draw:page.
>>
>> Besides chart:subtitle, are there other cases that should be mentioned?
> All elements that are not shapes and that use svg:x/svg:y :-)
>
OK.
>>
>> ***************************************
>>
>> 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.
> On a second thought you are completely right. I thing we should remove 
> "draw:shrink-to-fit" since it is absolutely redundant.
> But then we should change the description of the "style:shrink-to-fit" 
> to something more general.
How about:

******

The |style:shrink-to-fit| attribute specifies whether content is reduced 
in size to fit within a cell or drawing object. Shrinking means that the 
font size of the content is decreased to fit the content into a cell or 
drawing object. The attribute has no effect where content already fits 
into a cell or drawing object.

******

Hope you are having 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)