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

Hi Anthony,

Anthony Grasso a écrit :
> 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.
Thank you. This looks better I think.

> 
>>>
>>> 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.
I'm fine with this change.

> 
>>>   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?
I'm not sure. What do you mean by 'at a further distance' ? My concern was more a question of precision. It may happen than given the precision of the implementation and the type of the curve, even though mathematically the control point should be out, it will be in. So I'll change your last 'must' into a 'should'.

> 
>>> 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?
I'm not sure. The first sentence mentions that the BB is 'applicable' only to elements with display other than none. So, since defs is equivalent to display=none, therefore the BB should not be applicable. But your last sentence seems to say that defs must return something. I guess it all depends on the meaning of applicable. If not applicable means bounding box = '0 0 0 0', then it's ok.

> 
>>>
>>> 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".
Fine.

> 
>>> 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].
Fine.

> 
> 
> Please let us know at your earliest convenience if the changes are 
> satisfactory.
Except for my two remarks above, I'm satisfied. Thanks.

Cyril
> 
> 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 
> 


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat

Received on Wednesday, 15 October 2008 23:49:38 UTC