Repository navigation
Layout managers have problems with titles containing MathText #11468
Description
Layout managers seem to have problems with titles containing MathText.
One would expect to have a title which neither overlaps with the axes nor with the figure boundary in all cases depicted below.
tight_layout
multi line title
as expected
multi line title with MathText
The title is a bit squeezed towards the top figure boundary, but does not go beyond it, nor does it overlap the axes. This is somehow still acceptable.
single line title with MathText
Here the title overlaps with the axes. This is in thus far strange because in the case above with multiple lines, this overlap does not occur.
constrained_layout
multi line title
as expected
multi line title with MathText
The title exits the figure. This is not desiredeable.
single line title with MathText
Here the title overlaps with the axes.
code
import matplotlib
import matplotlib.pyplot as plt
plt.rcParams['savefig.facecolor']='#e9f7fd'
def create_bug(title="", constrained_layout=True, i=0):
plt.figure(constrained_layout=constrained_layout)
plt.plot([0,1,2],[0,1,1])
plt.title(title)
if not constrained_layout:
plt.tight_layout()
tx = "tight_layout"
else:
tx = "constrained_layout"
plt.text(0.4,.95, tx, va="center")
plt.savefig(tx+str(i)+".png")
titles = ['line $\sum_{i} x_i$',
'multi-\nline $\sum_{i} x_i$',
'multi-\nline']
for layout in [True, False]:
for i, title in enumerate(titles):
create_bug(title, layout, i)
Matplotlib version
- Operating system: Windows 8.1
- Matplotlib version: 2.2.2, current master
- Matplotlib backend : Qt5Agg
- Python version: 2.7, 3.6
Activity
jklymak commentedon Jun 20, 2018
Thats because we have no way of knowing the text size other than by the fontsize. If we stick a huge symbol like
$\sum_{i}$in there, we don't know that its so much larger. I'm not sure what particularly can be done about this w/o a lot of work in theget_tightbboxcode for the text.ImportanceOfBeingErnest commentedon Jun 22, 2018
Sure? If only fontsize matters, how do you find out the difference between "iiiiiiiiiii" and "mmmmmmmmmm", which clearly is accounted for, e.g. in the case of ylabels.
See e.g. this image.
Here are the boxes for the text obtained via
get_window_extent()for the respective cases:tight_layout
constrained_layout
Seeing this it might be understandable that the multiline with mathtext (middle column) is cut on top. But what is really strange is that in the case of the single line (right column), the bounding box is actually correct, but still overlaps with the axes.
So in total those might be two different issues:
jklymak commentedon Jun 22, 2018
OK, the last column the problem is that neither layout manager cares if the title overlaps the axes. Thats the fault of where the title is being placed. If you call w/ no layout manager the i still overlaps. The way the layout managers work is by adjusting the size of the axes assuming a border that takes up the other decorators; here the layout managers are doing the right thing from their point of view. If we wanted something that does a better job of positioning axes that could be done separately.
The middle column is definitely just a problem with the bbox from multiline w/ text. Multi lines are hard: #9775
jklymak commentedon Jun 22, 2018
Hmmm, though #9498 should have taken care of the right hand column case. I'll need to see whats going on there.
jklymak commentedon Jun 22, 2018
Ah... #9498 only does its thing if the xaxis is on top. An easy fix is to also move the title if it overlaps the actual axes. My only concern there is performance because I think the axes tightbbox calf can be expensive.
jklymak commentedon Jun 23, 2018
OK, not finding a nice consistent way to do this. OTOH, note that there is a pad argument now for
set_title, so the user can simply specify a larger pad (in points) to get the title far enough away from the axes. #9816 and https://matplotlib.org/api/_as_gen/matplotlib.axes.Axes.set_title.htmljklymak commentedon Jul 8, 2018
@ImportanceOfBeingErnest please see #11499 and #11502. I think together they solve the issue here...
ImportanceOfBeingErnest commentedon Jul 9, 2018
Yep, it seems so. Once they are merged, this can be closed.