It is also worth noting that, previously (in main) for test_backend_pdf::test_hatching_legend the expected and generated PDFs were different, but the corresponding PNGs are same. So the ImageComparision passes, although the PDFs are dissimilar.
It looks like the expected PDF is generated with hatch_linewidth as $0$, while the actual PDF is generated with hatch_linewidth as $1$.

	Expected	Actual
PDF
Corresponding PNG

the PDF backend does some shady stuff by thickening them in the corresponding PNG

Yeah, there is something strange going on, see, e.g., #24263 which has a similar problem.

For the PR, I think it makes sense, but wouldn't it be possible to conditionally execute the added line based on which hatch is created? Or am I missing the point of the for-loop?

but wouldn't it be possible to conditionally execute the added line based on which hatch is created? Or am I missing the point of the for-loop?

I think this isn't possible, because of certain cases where the hatch could be a combination of marker and line hatches, for instance */.
It looks like the for-loop in writeHatches iterates through the hatchpattern of different objects.

@oscargus @jkseppan I would like to know your thoughts on this PR.

It is also worth noting that, previously (in main) for test_backend_pdf::test_hatching_legend the expected and generated PDFs were different, but the corresponding PNGs are same. So the ImageComparision passes, although the PDFs are dissimilar. It looks like the expected PDF is generated with hatch_linewidth as 0 , while the actual PDF is generated with hatch_linewidth as 1 .

Looks like the baseline images were changed in #29908, so this is no longer the case. The linewidth has been set to 1 since #28048, so you shouldn't see this difference any longer.

The reason that linewidths of 0 and 1 look similar when compared is probably because we do the rasterising without antialiasing (something like the -dTextAlphaBits=4 -dGraphicsAlphaBits=4 options to GhostScript) and a linewidth of 0 means "as thin as possible on the output device". It's been that way since 8c60d5c, and I think the reasons were performance concerns and that it sometimes hides small font differences, when you have the same font metrics but slightly changed fonts (which does happen at least with TeX fonts). Since then we've removed text from most baseline images, and perhaps the performance concerns are not that important, as the tests take a long time in any case. We might want to revisit the way the comparison is done.

This causes various line-based hatches to look thicker, depending a little on the renderer used. The hatches have always been rendered in PDF with a fill+stroke operation, but now that there is a fill color in all hatches, the lines get "filled" which adds some pixels.

Would this cause hatch patterns 'o' and 'O' to be filled? They are documented in hatch.py to be unfilled (and '.' is a small filled circle, and it does not seem to be documented whether '*' is filled or not).

Would this cause hatch patterns 'o' and 'O' to be filled? They are documented in hatch.py to be unfilled (and '.' is a small filled circle, and it does not seem to be documented whether '*' is filled or not).

It doesn't! The circle paths are drawn forward and backward when the circles are not meant to be filled, presumably for this exact reason.

That leaves the "filled" lines which get extra pixels. This is only a problem at low resolution and don't seem to be an issue when viewing with a PDF viewer, so perhaps not worth fixing. The fix would likely involve changing hatch.py to return multiple paths along with "stroke" and "stroke+fill" data, instead of the current single noncontiguous path that gets stroked and filled.

If we add antialiasing and increase the resolution, only clip_path_clipping.pdf would need to be changed and the other tests would pass with the baseline pdfs in main.