Looks promising!

If you can add info here:

Here one can see that it is working:

I'll add some comments in the code as well.

There is a failing test at the moment. It should just be to update the test image so that includes the ellipse as well.

This is the current test image:

which will now also include the ellipse. So updating that image after rerunning the test, copying from result_images to baseline_images will have the tests pass and the new code tested.

Oh, and I think that it may be worthwhile to highlight this addition through a What's new note. If you want to, write some short text and a minor example showing how it can be used. See examples is https://github.com/matplotlib/matplotlib/tree/main/doc/users/next_whats_new

Looks good, thank you @ckcherry23 ! We are just waiting for a second review.

Agree that it looks good! Let me just check the equations (now it seems like the padding is scaled, but I cannot really get my head around it as it looks like the padding is scaled down by sqrt(2), but in the image it looks like the padding has increased if anything).

OK, there is a slightly different behavior of the pad here, but I am not sure if it is a problem or not. Nor if it is worthwhile to redo the code.

Here is what happens with circle, this and what possibly may be a preferred interpretation of pad:

As seen, for circle, the leftmost, the padding is on the radius of the circle. For this PR, the middle, the padding is on the bounding box and then the ellipse is touching the padded box. One may think that the padding could be as in the rightmost figure, but I do not think that it is a problem as one probably will try to figure out a good padding anyway.

(I also realized that with pad=0 a circle does not always enclose all the text. One can try this with plt.text(0.5, 0.5, "M", bbox={'boxstyle': 'circle,pad=0'}, fontsize=40).)

I'll approve this as the code is good as such, but not merge it to get a second opinion on the behavior.

Thanks for your effort!

• Pro of just merging now: get it in!
• con of just merging now: may have to regenerate a test image

@oscargus how are you defining the angle on the pad in the above? Is it going through the center of the text bounding box?

That was my idea, yes, as that seems to be a quite natural way to define it, closest distance to the bounding box (although any angle will have that...). But I guess that there are more options, like 45 degrees.

Considering that the Circle pad is a bit different compared to the others, I am not sure if it actually matters that Ellipse is a bit "off" as well. I guess my main idea was that the pad should be visually similar for the same value.

Another reason is that the equations become a bit easier for that case, compared to e.g. 45 degrees, although the computational burden is not that huge anyway.

Edit: actually, they are straightforward for 45 degrees as well.

On a bit more consideration I think that there are a bunch of reasonable definitions of pad and there is really only one degree of freedom here. It is not clear to me one definition of pad is more obviously right or more natural nor is it clear that the definition of pad should be consistent between different annotations styles (I expect these to be tuned by what "looks good' and I really hope that people do not try to encode quantitative information into the size of the annotation boxes over what is needed to fit the text....). In addition to the two proposal I could also see pad being what is needed for either the major or minor axis to be tangent to the sides of text size (which seems to be the generalization of Circle's pad?).

I'm in favor of merging this as-is and accept the apparent inconsistency because the inconsistency is inevitable.

Thanks @ckcherry23 ! Hope to see you around!