Re: Bounding Box Calculation

Gavin,

On Tue 30 Sep 2003, Gavin Kistner wrote:

> 
> Using ASV3, I noticed that:
> 	<svg
> 		width="800" height="600"
> 		viewBox="0 0 800 600"
> 		style="overflow:hidden"
> 		onresize="alert(document.documentElement.getBBox().width)">
> 			<rect x="-100" y="-100" width="1200" height="1200">
> 	</svg>
> results in '1200' and not '800' being alerted.
> 
> The SVG 1.1 specs don't seem to explicitly cover how to compute the 
> bounding box depending on the value of the overflow style, but they 
> generally indicate a simple calculation method which could be 
> interpreted to exclude this property.
> 
> 	"The bounding box is computed exclusive of any values for clipping, 
> masking,
> 	filter effects, opacity and stroke-width."
> 	- http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox

I think this covers the overflow style as well.

> It is my (rather strong) opinion that such a calculation technique, 
> while convenient for the UA developers, makes the bounding box rather 
> pointless. 

Maybe I misunderstood, but do you suggest that the bounding
box should be clipped by the viewport? ie. that things that
are off the side of the canvas should have a empty bounding
box?

> Using:
> 	overflow:visible
> should include child elements who stray outside the viewBox in the 
> bounding box calculations, but
> 	overflow:hidden
> should not. 

I'm not sure why this is useful. Could you give
a use case? Also, remember that you can already work
this out using script, but removing the functionality would
not provide the inverse (ie. if we made the change you 
suggest you wouldn't be able to find the real bbox of
things).

Also also... the bbox is in userspace, not the
viewport's coordinate system.


> Similarly, if I have
> 	<g><circle ... r="10" style="stroke-width:200"/></g>
> then the bounding box width is '220' IMO. Handing me '20' is of little 
> use.
> 
> 
> 
> The SVG 1.2 draft mentions the possibility of such an improvement:
> 
> 	"In order to provide greater flexibility and expressive power, it 
> might make sense
> 	to simultaneously add new utility methods in the SVG DOM, such as 
> improvements
> 	in area of geometry queries (e.g., bounding box queries that take 
> 	into account things
> 	such as stroke widths and filter effects)."
> 	- http://www.w3.org/TR/SVG12/#rcc-uiwidgets
> 
> and I would heartily encourage the changing of the word 'might' to 
> 'definitely'. :)

To be honest I know we've discussed this, but I can't
remember if they were accepted.

It isn't in the list of things that will be added to
the next SVG 1.2 draft, so I'll have to check more carefully.

> If you don't want to break existing 1.1 scripts, then perhaps the 
> addition of
> 	SVGLocatable.getExtendedBBox()
> might be in order.

Definitely.

Dean

Received on Monday, 6 October 2003 11:44:53 UTC