Re: [svg2] getStrokeBBox functionality has been replaced with getBBox dictionary argument

Hi David,

David Dailey wrote:
> I'm not sure why we'd want to allow so poor an approximation as the
> bounding box of the control points (which could be very much looser
> than the curve itself).
>
> Consider the behavior of FF, IE, Opera (good Opera) versus that of
> Chrome and Safari for the seven pointed, planar four-regular graph on
> 14 nodes at http://granite.sru.edu/~ddailey/svg/BBox0nvb.svg (ya'll
> like stars right?).

Nice example.  Perhaps it is OK to require the exact bounding box and
not allow the control point approximation.

> So I'm not sure why the spec would want to allow approximations,
> especially ones so sloppy as to revert to the control points.
>
> Then on to my question: defining the bounding box for strokes to
> include markers seems nice, but I suspect dashes are more prevalent
> and just as likely to disrupt the geometry of the shape (around the
> corners of things where dashes either appear or don't). Would it be
> much more work to consider the effects of dash-array on the stroke's
> geometry than to consider the effect of markers? Not a big issue for
> me, but one which arose in reading the suggestions.

Note that getBBox({ fill: true, stroke: true }) would include the stroke 
shape but not markers; you'd need to say markers:true to explicitly 
include the markers.

As to whether dashes should be included: one thing we want is the 
ability to get the bounding box that explicitly doesn't include the 
effect of dashes, so that if you are doing something like animating the 
dash array to get a marching ants effect your bounding box wouldn't keep 
changing.  But we certainly could have an option to control whether 
dashes are followed.

Getting the bounding box of the stroke shape is another case we might 
like to consider whether an approximation is OK (which we also discussed 
during the F2F).  It's common for implementations (including Firefox) 
when computing the area of the canvas to invalidate when a path with 
stroke changes to inflate the geometry bounding box by a value that 
takes into account stroke-width, stroke-linecap, stroke-linejoin and 
stroke-miterlimit, which often gives reasonable bounds but can overshoot 
a bit.  Calculating the exact bounding box of the stroke shape is 
certainly harder than for the geometry (seeing the closed form 
expressions in the page you linked to above).

Received on Tuesday, 4 February 2014 20:52:22 UTC