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: Re: [office] ODF CD01: Responses to editorial notes in the graphicschapter



I do have some follow up questions:

dr3d:lighting-mode, when used with 3D objects, we now say:

> The |dr3d:lighting-mode| attribute specifies the lighting algorithm 
> used to render a 3D object.
> The value of this attribute can be |standard| or |double-sided|. If 
> the value is |double-sided|, the reverse sides of the object are also 
> lighted.
My note and the response:

> Ed. Note We should define “standard” in some meaningful way.
> CL: “standard” should have named “single-sided” as it is the oposite 
> of “double-sided”, meaning that only front faces will be lit. Readers 
> with 3D knowledge will know what a front face is, others will not care 
> much...
Actually there is a more difficult problem than standard vs. double-sided.

Note first sentence says that the attribute "specifies the lighting 

We then say: "this attribute can be standard or double-sided."

And those are in fact the only values for this attribute.

I suppose one could argue that "specifies" means to choose between 
algorithms that illuminate the face of an object versus both sides 
rather than naming an algorithm but that sounds weak to me.


The dr3d:lighting mode attribute specifies the illumination of a 3D object.

The dr3d:lighting-mode attribute values are:

* standard - front face of an object is illuminated

* double-sided - front and reverse sides of an object are illuminated


18.134 draw:corner-radius

Now reads:

> The |draw:corner-radius| attribute specifies the radius of the circle 
> used to round off the corners of a caption |<draw:caption>|, rectangle 
> |<draw:rect>|, or a text-box |<draw:text-box>|.
My comment and the response:

> Ed. Note We need to say what happens if both draw:corner-radius and 
> svg:rx/ry are both present? Which one controls? Shouldn't 
> svg:rx/svg:ry be available for text-box and caption as well?
> CL: I would say the svg attributes control. And yes also for text-box 
> and caption.
> The |svg:rx| and |svg:ry| attributes can also be used to round off the 
> corners of a rectangle |<draw:rect>|.
So would the following be acceptable text:

The |draw:corner-radius| attribute specifies the radius of the circle 
used to round off the corners of a caption |<draw:caption>|, rectangle 
|<draw:rect>|, or a text-box |<draw:text-box>|.

The |svg:rx| and |svg:ry| attributes can also be used to round off the 
corners of a rectangle |<draw:rect>|.

If draw:corner-radius, svg:rx and svg:ry attributes are applicable to 
the corner of a rectangle, the value of the draw:corner-radius is ignored.

Note that adding svg:rx and svg:ry to the schema for draw:text-box and 
draw:caption would of necessity require the same explanation for the 
presence of draw:corner-radius and svg:rx/svg:ry.

It may be that elements should have either draw:corner-radius or 
svg:rx/svg:ry but not both. Quite possibly (in some future release) only 
one mechanism for all rounding of corners.




We currently say:

> The |draw:modifiers| attribute contains list of modifier values. The 
> modifier can be a float value.
My comment and the response:

> Ed. Note We don't define this “list” of values. Whitespace separated? 
> Isn't that a string, not a list?
> SJ: Yes, in XML context this attribute is a string. But this string is 
> encoding a list of integer and or float values (white space 
> separated). Other attributes (draw:enhanced-path, draw:formula, 
> draw:glue-points) are referencing to single entries of this list.
> modifiers::= modifiersequence?
> modifiersequence ::= number (' ' modifiersequence)*
> number::= sign? float | sign? integer
> float::= fractional exponent? | integer exponent
> fractional::= integer? '.' integer | integer '.'
> exponent::= ( 'e' | 'E' ) sign? integer
> sign::= '+'| '-'
> integer::= [0-9]+
> The draw:modifiers can referenced by other attributes as draw:formula 
> or draw:handle-position, indexing starts at 0.
Suggested revision:

The draw:modifiers specifies a white-space delimited set of signed 
integer or float values. These values can be referenced by other 
attributes by specifying an appropriate indexing value. Indexing starts 
at 0.

Glad you mentioned the references because I come up with:

draw:enhanced-path, draw:glue-points, draw:handle-position, 
draw:text-areas but no draw:formula searching on| "draw:modifiers| 

The reason for that omission is that under draw:formula we say:

> The |draw:formula| attribute specifies an equation that should be used 
> to evaluate a value. A formula can make use of other formulas or 
> modifier values by function and or modifier reference.
True enough the modifier reference is in the EBNF but we should make the 
prose consistent with the other instances.

I have inserted a new Ed. Note at that location as a marker.



We say:

> The |draw:path-stretchpoint-x| attribute with the 
> |draw:path-stretchpoint-y| attribute specifies the stretchpoint of a 
> shape.
My comment and the reply:
> Ed. Note We don't say if both draw:path-stretchpoint-x and 
> draw:path-stretchpoint-y must both be present or it is an error. It is 
> implied but not stated.
> SJ: They must not be present, as each attribute is having a default value.
Sorry, I don't understand the answer.

Can you say a bit more about that one?


I am going to start with draw:start-glue-point tomorrow.

Hope you are at the start of a great day!


Patrick Durusau
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]