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 guessMarkerStyle._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.