Re: What should the bbox of a path without a d attribute be?

Hi David,

On 24/04/2014 10:31 PM, David Dailey wrote:



On Wednesday, April 23, 2014 9:53 PM
Nikos Andronikos wrote:



RESOLUTION: Bounding box for path/polygon/polyline with no data set (empty


or zero valid commands) should not contribute to ancestor bounding box

Hi Nikos,

Everything else looks good to me, but I suppose that the above is to meant
to handle the case of unions of paths, as within a shared parent, like a
<g>, or, presumably (if ever implemented), a <veUnion>.

It's really meant to clarify the behaviour for the shape elements that use (none) as a default
value rather than zero.
e.g. rect uses zero as the default for x,y,width and height. path uses (none) as the default for 'd'.
It's well defined what happens with a rect with width or height of zero, but in
SVG 1.1 it was never explicitly specifed what the effect of having a value of (none) for d means.
This change clarifies that and makes path, polygon and polyline work like the other shape elements.

I am wondering if
there might be filters in which, through some sequence of the chaining of
filter primitives as in <feBlend> or <feImage>, there might not be a common
ancestor to two shapes, but where the net result would nevertheless be a
"union". We would still not want the bounding box to expand to include the
isolated empty point.

Sounds sensible to me although I can't think of an example off the top of my head.

Perhaps the SVG spec text should change
from:
"A call to getBBox<http://www.w3.org/TR/SVG2/types.html#__svg__SVGGraphicsElement__getBBox> on the element will return the same rectangle as if the element were rendered. However, an element that is not in the rendering tree does not contribute to the bounding box of any ancestor element."

to something more general:
"A call to getBBox<http://www.w3.org/TR/SVG2/types.html#__svg__SVGGraphicsElement__getBBox> on the element will return the same rectangle as if the element were rendered. However, an element that is not in the rendering tree does not contribute to any other bounding box."

Would be good to get comments from the others as to whether this is an important distinction to make.




In the case of a script which would perform such a union, perhaps without
the direct reconstruction in DOM of a common ancestor to the two geometries,
we still would not want the isolated point to be considered. Might the
following rewording clarify the intent more clearly?

The user script could check if the bounding box is (0,0,0,0) and not include that box in the
union. This would work fine, but I wonder if it might be useful to have an attribute on SVGGraphicsElement that
indicates that an element is not rendering.


modified RESOLUTION: Bounding box for path/polygon/polyline with no data set
(empty or zero valid commands) should not contribute to bounding box of its
union with  other shapes, e.g., as in a shared ancestor such a <g>.

I'm not sure, actually, if this is needed, but might it help?

Cheers
David





The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.