Can check carefully in a second, but doesn't the maximum amount of extra clipping box needed depend on the miter limit?

I would believe that it happens to occur at 45 degrees, but maybe documenting it that way is misleading?

Edit: default PDF miter limit appears to be 10 (https://help.adobe.com/pdfl_sdk/18/PDFL_SDK_HTMLHelp/PDFL_SDK_HTMLHelp/API_References/PDFL_API_Reference/PDFEdit_Layer/General.html), which means the longest possible miter will occur for an angle of around 11.5 degrees (https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-miterlimit).

P.S. Once #16832 gets merged, I'll be able to clean up #16607 to compute the "exact" Bbox for an arbitrary path given the stroke width and miter limit. Just dropping this reference here so I remember to also fix this code to set an exact clipping path once this is possible.

I don't believe so, because all markers have cap style of 'butt'.

Oh, default joinstyle is 'round', but some are 'miter'. I was a bit worried about that, but no markers in our tests or examples seem to have extended passed the sqrt(2) limit.

Yeah the only ones which are miter are e.g. X and other 90 degree angle-heavy guys. Since this code is marker-specific (and isn't called for general paths, where we might have much more acute angles), I'd say it's good to go as-is, but would still recommend rewording the comment to clarify that the only reason this works is because the built-in markers never have angles more acute than 90 degrees.

Nix what I said up there. We now allow custom markers and this will fail for those. I would recommend using an extra buffer of size "10/2" instead of "sqrt(2)/2" to account for the miter limit of 10 (your code worked because "sqrt(2)/2" is the miter limit that starts beveling after 90 degrees).

Actually, I guess MarkerStyle._joinstyle is private, so 45 degrees should work for now. Although we will have to be careful to fix this in the future if we go down a path like suggested in #16773.

Actually, I had focused on X initially, and that one is definitely 90° so 45° makes sense, but looking at triangles again, they are slightly clipped. You have to zoom in about 8x, but since PDF is vector, it's definitely there.

I updated the scaling to 5 as you said, to match the miter limit, and threw in some spec references. This fixes the triangles, 'v', '^', '<', '>', and diamond 'd', which are all markers with sharper corners.

I don't think my test triggers it, but I think we'd have to use huge markers to really see it. I'm a bit confused as to why, but I can confirm there's a difference when using the marker reference example.

Why did you need to change the baseline image? Here tests seem to pass without changing it.

TBH, I'm not sure, but I think it has to do with Ghostscript rasterization. If I run diffpdf on it, it sees no difference, nor if I just look at the two in a PDF viewer.

The tests fail with the old baselines for you?

They do, with ghostscript 9.27, if that's the problem.

I guess I would rather have this go on top of #17603 to avoid having to add a new baseline image.