- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Thu, 16 Oct 2008 01:34:20 +1100
- To: cyril.concolato@telecom-paristech.fr
- CC: SVG Working Group WG <public-svg-wg@w3.org>
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