Re: ISSUE-2129 (definition clarifications): Definition section is too long and needs clarifications (bbox, canvas, etc.) [Last Call: SVG 1.2 Tiny ]

Hi Cyril,

The SVG Working Group discussed this issue and agreed that the bounding box 
definition should be shifted if possible. Please see my comments below.

Cyril Concolato wrote:
> 
> SVG Working Group Issue Tracker a écrit :
>>
>> ISSUE-2129 (definition clarifications): Definition section is too long 
>> and needs clarifications (bbox, canvas, etc.) [Last Call: SVG 1.2 Tiny ]
>>
>> http://www.w3.org/Graphics/SVG/WG/track/issues/2129
>>
>> Raised by: Doug Schepers
>> On product: Last Call: SVG 1.2 Tiny
>> Cyril Concolato
>> <http://lists.w3.org/Archives/Public/www-svg/2008Oct/0110.html>:
>> [[
>> * Section "1.6 Definition"
>> Generally, I think the definition of bounding box is too long to be in 
>> the definition sections, it makes the definition section hard to grasp.
> For this comment, I propose to move the (unchanged) content of the 
> bounding box definition into a new section called "Bounding Box" before 
> "7.12 Object bounding box units". However, I don't know if adding a new 
> section has impact on the test suite organization for example. If you 
> think this is too much work, then ignore my comment.
> 

After going over the method used to generate the test suite, I decided that 
moving the "bounding box" definition to just before section 7.12 would be 
relatively easy and have little impact on the test suite. In summary the 
"bounding box" definition is now in section 7.12 [1]. The bounding box 
definition in the section 1.6 [2] has been reduced to a single sentence that 
references section 7.12.

Please note that this change has been made in the master version of the 
specification and thus does not show the example that is present in the 
published version. The changes and example will be incorporated in the next 
publication of the specification.

>>
>> Additionally, the definition of bounding box explicitely excludes some 
>> stroke attributes but not others like stroke-dasharray, join, cap. I 
>> suggest adding all stroke attributes.
> I suggest the following replacement:
> "The bounding box must be computed exclusive of any values for the 
> 'fill', 'stroke', 'stroke-width', 'opacity'  or 'visibility'  properties."
> With:
> "The bounding box must be computed exclusive of any values for the 
> 'fill' property, the opacity-related properties, the stroke-related 
> properties, or the 'visibility' property."
> 

I used very similar wording to that proposed. The replacement wording used for 
this changes is as follows:
"The bounding box must be computed exclusive of any values for the fill related 
properties, the stroke related properties, the opacity related properties or the 
visibility  property."

The reason for using "fill related properties" was to ensure that fill-opacity 
was included.

>>   This definition says:
>> "For curved shapes, the bounding box must enclose all portions of the 
>> shape along the edge, not just end points, but must not include 
>> control points for curves that are not within the shape itself."
>> The 'must not' requirement should be changed to a 'should' because 
>> depending on the curve and depending on the precision of the 
>> implementation (fixed point), it may be impossible to make a bounding 
>> box that does not include the control point. 
> There was actually a mistake in my comment. The proposed edit is replace:
> "For curved shapes, the bounding box must enclose all portions of the 
> shape along the edge, not just end points, but must not include control 
> points for curves that are not within the shape itself."
> with
> "For curved shapes, the bounding box must enclose all portions of the 
> shape along the edge, not just end points, but should not include 
> control points for curves that are not within the shape itself."
> 

As per your suggestion the "must not" was changed to "should not". I added an 
additional sentence at the end to help clarify the paragraph:
"For example, control points of a curve that are at a further distance than the 
curve edge, from the non-enclosing side of the curve edge, must be excluded from 
the bounding box."

Do you think this sentence helps with clarification of the paragraph?

>> Could you clarify the meaning of the following sentence especially for 
>> the defs element?
>> "Elements which do not partake in the rendering tree (e.g. elements in 
>> a 'defs'  element, elements whose 'display'  is none, etc.), and which 
>> have no child elements that partake in the rendering tree (e.g. 'g'  
>> elements with no children), shall not contribute to the bounding box 
>> of the parent element, but must return a bounding box for the sake of 
>> calculating their own geometry."
>> What does the bounding box of a defs element 'must return (...) for 
>> the sake of calculating [its] own geometry.'?
> For this comment, I don't know what edit to propose.
> 

I think this sentence was trying to say too much towards the end. I removed "but 
must return a bounding box for the sake of calculating their own geometry." from 
the end of the sentence and started a new sentence which says:
"Elements that do not contribute to the bounding box of a parent element must 
still return their own bounding box value when required."

Does this change help clarify paragraph or is clarification of the "defs" 
element still required?

>>
>> There are two related definitions: canvas and SVG canvas. Do you 
>> really need 2 different definitions? Where in the spec do you use 
>> canvas with a different meaning than SVG canvas ? It is not clear how 
>> these terms are used in the spec. For example, we find: target canvas, 
>> current canvas, intermediate canvas, resulting canvas, background 
>> canvas, and temporary video canvas.
> For this one, I think we could use only one word: canvas, using the 
> definition of SVG canvas. I'm not sure though.
> 

Agreed. The "SVG canvas" definition was removed and the few occurrences of it 
were changed to "canvas".

>> The definition of "graphics referencing element" misses the 
>> foreignObject element, no?
> This one is simple, replace:
> "The following elements are graphics referencing elements: 'animation', 
> 'image', 'use' and 'video'."
> with
> "The following elements are graphics referencing elements: 'animation', 
> 'foreignObject', 'image', 'use' and 'video'."
> 

Yes, this was an easy change. The change now appears in the master version of 
the specification [3].


Please let us know at your earliest convenience if the changes are satisfactory.

Kind Regards,

Anthony Grasso


[1] http://dev.w3.org/SVG/profiles/1.2T/master/coords.html#BoundingBox
[2] http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermBoundingBox
[3] 
http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermGraphicsReferencingElement

Received on Wednesday, 15 October 2008 14:35:08 UTC