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

Hi David

> 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).

Could be, but in my experience it is not all that common that it has as
major an effect as in your example.  Plus there are also use cases where a
fast and approximate bounding box is more desirable than a slow and
accurate one.  Perhaps one input to the algorithm might be a flag to
indicate that you would be satisfied with an approximation.

Paul





On 5 February 2014 05:24, David Dailey <ddailey@zoominternet.net> wrote:

> ------------
> 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:
>
>    https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
>
> ...
> ------------------
> 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
> http://granite.sru.edu/~ddailey/svg/BBox0nvb.svg (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.
>
> Cheers
> David
>
> [1] http://en.wikipedia.org/wiki/Minimum_bounding_box
> [2]
> http://www.scienceforums.net/topic/29295-calculating-coordinates-of-peaks-of-cubic-bzier-curves/
>
>
>
>
>
>
>