I noticed that the current version on master lost the right spines

while in the current online docs

In case this change is expected (might actually be due to #12716 ), I'd suggest to modify fig.tight_layout(pad=0) to fig.tight_layout(pad=1) or whatever is needed to have the complete axis drawn.

Even with fig.tight_layout(pad=0) the axes frame should be drawn completely. I consider this a bug in margin calculation. It should be fixed and not worked around in the example. Attn. @jklymak

I don't think this is a bug in the margin calculation. It's more that now that the axes extent is calculated correctly you see the same as you would see in a case where you have the axes span the entire figure:

import matplotlib.pyplot as plt
plt.rcParams["figure.figsize"] = (3,2)

fig, ax = plt.subplots()
fig.subplots_adjust(0,0,1,1)

plt.savefig("test.png")

So the underlying question is: Would a line that is at the edge of the figure need to be stamped to pixels by a different set of rules than other lines within the figure?

Since I don't expect there to an answer to this in the short term, my suggestion would still be to increase the padding for this example such that it looks good. After all, pad=0 is not relevant for the example and is chosen pretty arbitrarily.

@timhoffm the bbox calculation is correct. As @ImportanceOfBeingErnest says, the pixel stamping is putting the line on either side of that bbox depending on how many pixels are in the figure. I don’t think there is anything the bbox calculation that can take that into account because it is backend dependent.

That this “worked” before was because the axes bbox returned a random margin around the axes. I’d be against going back to that buggy implementation, and agree that adding a small pad is the way to fix this problem.

Ok, added a small padding.

Appveyor py37 is failing for some time with lib\matplotlib\mathtext.py:628: MemoryError. I'm unclear if their install is broken or if it's coming from mpl code.

Anyway, it's unrelated to this PR.

Yes, it needs a milestone: Canonically, it would be 3.1.1, but simple doc backports are still accepted for 3.1.0. I'm not setting this to 3.1.0 to not hold up 3.1.0 with open PRs. But whoever merges this before 3.1.0 is out, can set that milestone before merging.