Bounding box algorithm is not precise

[dirkschulze]

The algorithm in Bounding Boxes describes how to compute the different boxes sizes depending on the booleans fill, stroke, markers, clipped.

However, with the exception of fill, all algorithms have the description:

set box to be the union of box and [...]

However, box is specified to get initialized as (0,0,0,0) and therefore has an actual value. If box wasn't set to fill already, then all boxes will include the point (0,0) which is not what we want to have.

Maybe we should let each boolean initialize box to the value returned by each operation if it isn't initialized already, otherwise create the union of box and the specific rects.

Edit: Stroke bounding box includes the fill bounding box, always. Therefore, for stroke we can also just initialize box to the computed stroke bounding box if the value of stroke is not none.

If either none of the flags was set or no operation initialized/contributed to box, initialize it to (0,0,0,0) and return box.

Personal note: The dictionary might not be easy to feature detect. It might be quite some work to figure out which flag is supported by an implementation or not.

[dirkschulze]

In addition, the stroke shape computation code is not specific enough:

with the assumption that the element has no dash pattern

There is more that contributes to the stroke bounds:

• line joins,
• mitter,
• line caps.

The algorithm in the mask spec is more specific: https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box This algorithm is used for stroke-box CSS key value as well.

Maybe we should just reference that one.

[BigBadaboom]

The CSS stroke bounding box algorithm is fairly loose. It exaggerates the bounds a lot for shapes that use mitred joins. A mitre limit of 10 is fairly typical (it is the PDF and PS default). So the padding around any shape would be five times the stroke width.

See demo: https://jsfiddle.net/5y8zt05h/18/

I'm not sure that the CSS algorithm would be suitable in the SVG context.

[dirkschulze]

@BigBadaboom Please take a look at the linked algorithm first. This is not fairly loose but very specific and for SVG elements exclusively.

[BigBadaboom]

Bad choice of words on my part, I guess, I meant loose in the sense that it is not a very tight bounding box.

[dirkschulze]

@BigBadaboom for strokes it is not the tight bounding box. For Masking, transform, fill and stroke and many other specs it has the very practical reason that graphic libraries provide different boxes for the stroke bounding box depending on their capabilities. For a keyword like stroke-box we need more predictability.
To compute those boxes w/o replicating the complexity and work a graphics library usually already does in an underlying-implementation independent manner is non-trivial and very performance consuming.
The mentioned algorithm is trivial and fast, returns the tight bounding box for basic shapes, otherwise a bounding box that guarantees that the stroke is inside the box and still the smallest rectangle based on heuristics (but not the tight bounding box).

[BigBadaboom]

@dirkschulze If that is the case, then I think the Bounding Box section of the spec will need to be updated. The paragraph starting "For curved shapes, the bounding box..." gives the strong impression that all bounding boxes should be tight.

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation milestone to clean this up before 2.0 REC