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

Monday, February 03, 2014 11:19 PM
Cameron M writes:

Per our discussion during the F2F last week (resulting in ACTION-3581), I've removed getStrokeBBox from the SVG 2 draft and extended getBBox with an optional dictionary argument that can be used to select which parts of the element contribute to the resulting bounding box.  To that end I've added an algorithm that describes how to compute the bounding box:

Hi Cameron,

What you've described in the algorithm makes sense to me with one exception and a (probably unimportant) question:

When it says:
>Issue 12We should say something about allowed approximations such as using the bounding >box of a B├ęzier segment's control points.

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 (ya'll like stars right?).

I would assert the following:
a) the behavior of Chrome and Safari is inexcusable.
b) authors expect the bounding box of a shape to conform to the shape and not to some underlying abstraction (typically using <replicate> or SVG or something of that ilk) from which the shape has been generated.
c) a spec that allows such loose bounding boxes to be called bounding boxes has used the term 'bounding box' inconsistently with its meaning in common parlance [1].
d) While finding minima and maxima of cubic or quadratic Beziers isn't trivial, I don't think it is insoluble either. IE, FF and Opera-good do quite a reasonable job and Frank Bruder seems to have described a closed form solution [2]. The local max (or min) of the stroke of a Bezier would seem to be given by merely offsetting the Bezier by stroke-width/2 pixels in the direction perpendicular to the curve's slope at that point

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.



Received on Tuesday, 4 February 2014 16:25:10 UTC