1299876 - The size of referenced stroke-box is not correct for graphics element with stroke-linejoin or stroke-linecap assigned.

Status: NEW

(Core :: Layout, defect, P3)

Description

[u459114]

https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box

If element is not <rect>, <ellipse>, <circle> or <image> just follow one of the following conditions in the order they apply:
the used value for stroke-linejoin is miter
1. Let miter be the used value of stroke-miterlimit.
2. If miter is smaller than the square root of 2 and if the used value for stroke-linecap is square, multiply delta with the square root of 2. Otherwise, multiply delta with miter. 
the used value for stroke-linecap is square
1. Multiply delta with the square root of 2. 

SVGPathGeometryElement::GetGeometryBounds does not support this formula yet.

Create this issue to tracing this work

Comment 1

[u459114]

1. Add a new type BBoxFlags::eBBoxIncludeStrokeBox(??)
2. Find a way to bring this new enum type into 
   SVGLineElement::GetGeometryBounds
   SVGPathGeometryElement::GetGeometryBounds
   nsSVGPolyElement::GetGeometryBounds
   nsSVGTextElement::GetGeometryBounds
3. Apply the formula defined in spec in these functions.

Comment 2

[u459114]

Attachment: Bug 1299876 - Part 1. Inflate bbox by stroke used value of the target frame.

Review commit: https://reviewboard.mozilla.org/r/82746/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/82746/

Comment 3

[u459114]

Attachment: Bug 1299876 - Part 1. Correct the algorithm of stroke box computing.

Review commit: https://reviewboard.mozilla.org/r/82840/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/82840/

Comment 4

[u459114]

Attachment: Bug 1299876 - Part 2. Reftest of stroke box computing.

Review commit: https://reviewboard.mozilla.org/r/82842/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/82842/

Comment 5

[Cameron McCormack (:heycam)]

Sorry for the delay looking at this.  There is another definition of "stroke bounding box" in the SVG 2 specification, which I think is more recent than the one in the Masking spec, but I am not sure.

https://www.w3.org/TR/SVG2/coords.html#BoundingBoxes

("Stroke bounding box" is defined by reference to that general algorithm, right at the end of the "Bounding boxes" section.)

I remember having discussions with Dirk about whether the definition should include a specific way to handle stroke-{linejoin,miterlimit,width}, but I don't remember what the outcome of that was.  But I can see that the definition in the Masking says to take the regular bounding box and inflate it with a value based on those three properties, while the definition in the SVG 2 spec says just to return the tightest box that contains the stroke shape, without saying how to do that.  I think Dirk's reasoning was that it wasn't clear how to compute the tight bounding box of the stroke shape, so the Masking spec should define exactly how to produce a stroke bounding box, even if it might result in a box bigger than it needs to be.

Do other browsers implement the stroke-box reference box yet?  If so, do they follow the definition in the Masking spec, the SVG 2 spec, or something else?  Also, the definition in the SVG 2 spec is also used for svg_element.getBBox({ stroke: true }), so it might be useful to see whether we and other browsers differ in that.

Comment 6

[u459114]

(In reply to Cameron McCormack (:heycam) from comment #5)
> Do other browsers implement the stroke-box reference box yet?  If so, do
No, chrome & safari do not support it in release and developer version.
> they follow the definition in the Masking spec, the SVG 2 spec, or something
> else?  Also, the definition in the SVG 2 spec is also used for
> svg_element.getBBox({ stroke: true }), so it might be useful to see whether
> we and other browsers differ in that.

The definition of stoke box in these two spec is different. Let me figure it out before ask review.