I pushed a couple minor tweaks:

1. Changed the box to get its colour from the text. This isn't used in these tests, but could be elsewhere.
2. Removed the edge colour from the box.
3. Added a comment about the bounding box size.
4. Tweaked the importing so that there's only one fixture.

I made one more change to 2 tests that I found in#29816 that are about tight layout, namely that callingfig.tight_layout() within the test, withimage_comparison(..., remove_text=True) does not layout correctly. The text would be removed after the layout, and thus the test image was still beholden to text properties.

I fixed this by setting the layout on the Figure itself, so it would be enabled on save and correctly ignore text. Also, I changed the table test to use placeholders.

While updating that doc section, I was also reminded that we should prefermpl20 style. I guess I should update all of these, though it would change a bunch of figure sizes and also where the ticks are, so I'm not sure if I should for the layouting tests. That change would be here:https://github.com/QuLogic/matplotlib/compare/layout-text-placeholders..ltp

I would do the mpl20 change in one go. I checked the diffs: The smaller figure sizes are ok. AFAICS no layout information is lost. The only one I'm not sure about istight_layout_offsetboxes2.svg

The offset boxes (red/green) and the labels of the right column overlap. But I guess that's just how tightlayout works. It does not account for the actual label sizes.

Tight_layoutshould account for the actual reported label sizes.

So is this an issue due the rectangle not representing the actual text width but rather an approximation?

I'm not sure - I dont' see an equivalent test for constrained layout - but maybe it is a draw twice sort of error, where the offset boxes get moved when the axes gets resized, and therefore the margin made for the axes is too small for th new position. We run constrained layout twice to get around that; usually the position is "closer" after the first time and the new margin is big enough.

Hm@QuLogic maybe the workaround here could be to increase the figure size to not be bothered with this topic right now? 🤯 Not great, but digging into whether this is a tightlayout issue or a box approximation issue also does not feel like a good use of time. And I don't like the present image with the overlap.

Tight_layoutshould account for the actual reported label sizes.

But these are not labels, they areAnchoredOffsetBox. Trying it out with constrained layout, it also doesn't seem to interact with the ticks either.

Based on the comment in the test, it appears the intention is to ensure that the boxes are included in the Axes bounding box, but not necessarily have any effect on the ticks labels. Then thereal test is the difference between 1 and 2, where the invisibleAnchoredOffsetBox don't count for the bounding box in the latter, and it looks like that property is preserved.

So I think that a) we can drop this test down to just .png since it's really just checking if a specific artist is included, b) maybe we should remove the tick labels entirely to avoid confusing ourselves, and c) maybe this doesn't need to be an image test at all?

Oh I see. Yes the boxes can overlap the labels in their own axes. They should not overlap labels in other axes.

Here's my suggestion for removing the image from the test:b6dff32

It creates 3 figures:

1. one without anyAnchoredOffsetbox
2. one withAnchoredOffsetbox around eachAxes
3. one with them invisibleAnchoredOffsetbox

Then the test is that in figure 2, eachAxes is smaller than in figure 1, and no boxes overlap. And then for figure 3, it's that it is the same as figure 1.

If that makes some sense, then I'll rebase this PR on top of that, so we can drop the figures before changing them here.

I am 👍 on moving to the version of that test that@QuLogic has proposed and moving all of these to mpl20 style in this PR.

I think that this is the next PR in the sequence to move to freetype 2.13