I've just noticed that by not passing the stroke, the bbox will be wrong for rectangles created by the typst_layout::shapes::simple_rect function such as:

#rect(
  width: 100pt,
  height: 100pt,
  stroke: gradient.linear(green, black, yellow, angle: 90deg).sharp(8) + 20pt,
)

The gradient is not spreading to the edge of the stroke (the weird clipping in the converted PDF is an issue that should be fixed in a newer hayro version)
report.html

So essentially the special handling for rectangles also has to check if the paint is converted for the stroke or the fill of the rectangle shape.

EDIT: It's probably desirable to have the same transform as the rect fill here, so let's just leave this as is 🤔

I thought about it again, and I think for consistency it would actually be better to use different bboxes, i.e. use the tight bbox-without-stroke for the fill gradient, and the extended bbox-with-stroke for the stroke gradient.
Here's an example with a rect, rect(radius: 20pt), curve and circle:

Before PR	Current state of PR	Proposed

Reasoning:

• Before PR: uses bbox-without-stroke for both fill and stroke, this breaks gradients on lines, curves etc. where the bbox size collapses
• Current state of PR: Uses bbox-with-stroke for strokes on lines and curves but also changes bbox for some fills. This leads to inconsistency because of the special handling for rects. For round rects the situation is more complex as fill and strokes are handled separately and the codepath that generates the fill is not aware of the strokes (I think the reason being that strokes can be different for the four edges). So using the bbox-with-strokes for the fill is currently not possible.
• Proposed: Keep using the bbox-without-stroke for fills as before, and use bbox-with-stroke for all strokes (even for rect to handle zero-sized rects with strokes). This results in different bboxes for fill and stroke, but is consistent across shapes, predictable and backwards compatible with respect to gradient fills.

Note that the test "gradient-fill-and-stroke", which with the current state of the PR still passes, would change with the proposed version.

As it's a bit difficult to see, here a variant with a sharp gradient and different colors:

It's a design decision (at least until linear gradient start/end point can be controlled, see #2282).
Let me know what you think.

Note that the test "gradient-fill-and-stroke", which with the current state of the PR still passes, would change with the proposed version.

That's what I thought of when I wanted to dismiss this comment, but I didn't think of the other cases where this already happens because the rectangle is decomposed into different shapes.

I thought about it again, and I think for consistency it would actually be better to use different bboxes, i.e. use the tight bbox-without-stroke for the fill gradient, and the extended bbox-with-stroke for the stroke gradient.

I agree, we definitely either want the state Before PR or the Proposed one, not the in-between we currently have. Since the Before PR state wouldn't allow properly and consistently dealing with gradients on strokes, I think it's better to opt for your proposed changes.

Maybe the use case of gradient-fill-and-stroke can be revisited together with relative gradients and tilings at some point. But at least for the example shown, just removing the stroke and using an outset should be enough to replicate it.

Okay, I applied the proposed changes and replaced the gradient-fill-and-stroke test

Also did some more refactoring, including what you suggested earlier:

Then we could get rid of the bbox_size, and [...]
Finally we could add a Shape::bbox() method, which uses the shape's stroke field, since that seems to always be passed anyway.
This refactor can be done in a follow-up PR, it just feels like this would remove a lot of the complications.