You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The window extent of the axes does not coincide with their position in the figure. This issue occurs in Agg and Cairo backends.
Code for reproduction
The following code produces two axes. A green rectangle is drawn at the bounding box of the axes. A red rectangle is drawn in the space between the axes.
_base.py extends the bbox by self.xaxis.get_tick_padding() and self.yaxis.get_tick_padding(), for, you know, whatever reason. Particularly annoying, as these boxes do not at all cover the ticks; they seem to be in the wrong units...
OK, so the issue was dpi was not being taken into account. And that the algorithm assumed ticks around all the spines.
Currently
ax.get_window_extent currently gives the extent of the axes plus a pad aroudn the outside that is supposed to be the size of the ticks. It applies this regardless of whether the ticks are shown on that axis or not, though it does account for ticks that point in or out.
ax.get_tightbbox currently also accounts for the axis objetcs and all artists in the axes.
Proposal
ax.get_window_extent properly account for tick visibility on each spine.
Don't know if this is the place to bring this up, but I have noticed that this also happens when calling gridspec tight_layout and attempting to set zero as padding. So if you want to introduce a pad in one dimension (eg. h_pad=0, w_pad = 0.5), you need to gs.update the wspace or hspace to achieve the expected.
Activity
jklymak commentedon Nov 1, 2018
_base.pyextends the bbox byself.xaxis.get_tick_padding()andself.yaxis.get_tick_padding(), for, you know, whatever reason. Particularly annoying, as these boxes do not at all cover the ticks; they seem to be in the wrong units...jklymak commentedon Nov 2, 2018
I'll self-assign and try to fix this....
jklymak commentedon Nov 2, 2018
OK, so the issue was dpi was not being taken into account. And that the algorithm assumed ticks around all the spines.
Currently
ax.get_window_extentcurrently gives the extent of the axes plus a pad aroudn the outside that is supposed to be the size of the ticks. It applies this regardless of whether the ticks are shown on that axis or not, though it does account for ticks that point in or out.ax.get_tightbboxcurrently also accounts for theaxisobjetcs and all artists in the axes.Proposal
ax.get_window_extentproperly account for tick visibility on each spine.djakubosky commentedon Nov 2, 2018
Don't know if this is the place to bring this up, but I have noticed that this also happens when calling gridspec tight_layout and attempting to set zero as padding. So if you want to introduce a pad in one dimension (eg. h_pad=0, w_pad = 0.5), you need to
gs.updatethewspaceorhspaceto achieve the expected.jklymak commentedon Nov 2, 2018
Thats the same bug. #12716 gives the correct layout.