When subplot.xaxis.tick_top() is used, then the position of the plot title is not recomputed. Ideally, it should be shifted further up. Example code is as follows
The traditional fix which seems to have been used in axes.spy and axes.matshow is to set the y position of the title to axes.get_title.set_y(1.05), but there are obvious pitfalls with this approach...
Looking at #1109, does that mean this is not going to be fixed soon, or does it mean this is fixable now but #1109 would provide a more elegant overall solution? We may try a workaround on the Sage end, but if there is a patch we could apply to mpl, that would be even better.
I see the mention of QML in #1109. The ideas in QML seem quite similar to the ones in edje, which is one of the libraries behind enlightenment and has been around for nearly a decade ( see http://www.enlightenment.org and http://docs.enlightenment.org/auto/edje/ ). So, it might be useful for you to look at that project since all the theming and layout in enlightenment happens through edje.
but there are obvious pitfalls with this approach...
I have just trawled the axes.py module and looking at it, anything which extends beyond the plotting area is done in this way (axes coordinates outside of the range 0 <= x <=1), so while this approach obviously has pitfalls, it is also consistent with how the title and tickmarks are already being done...
I think that if there is going to be a partial fix for this any time soon, it will be via using the same logic for the titles as we are using for the xlabel and ylabel. They are already taking into account the ticks and tick labels. An additional wrinkle might be the case of twinned axes; the title-positioning logic for either axes would have to check for ticks and tick labels on both axes.
Activity
pelson commented on Oct 19, 2012
Definitely another one for the #1109 folio.
The traditional fix which seems to have been used in axes.spy and axes.matshow is to set the y position of the title to axes.get_title.set_y(1.05), but there are obvious pitfalls with this approach...
kcrisman commented on Oct 19, 2012
Looking at #1109, does that mean this is not going to be fixed soon, or does it mean this is fixable now but #1109 would provide a more elegant overall solution? We may try a workaround on the Sage end, but if there is a patch we could apply to mpl, that would be even better.
ppurka commented on Oct 19, 2012
I see the mention of QML in #1109. The ideas in QML seem quite similar to the ones in edje, which is one of the libraries behind enlightenment and has been around for nearly a decade ( see http://www.enlightenment.org and http://docs.enlightenment.org/auto/edje/ ). So, it might be useful for you to look at that project since all the theming and layout in enlightenment happens through edje.
pelson commented on Oct 19, 2012
I have just trawled the axes.py module and looking at it, anything which extends beyond the plotting area is done in this way (axes coordinates outside of the range 0 <= x <=1), so while this approach obviously has pitfalls, it is also consistent with how the title and tickmarks are already being done...
pelson commented on Oct 19, 2012
No, it is not even clear how what is going to be implemented at this point, we are still very much at the brainstorming stage.
@ppurka : please feel free to put your suggestions in the geom manager issue - what you are saying sounds very sensible indeed.
Cheers,
matplotlib#1415 [Arvin, Khodier]: Fixed overlapping x-axis ticks and …
matplotlib#1415 [Arvin]: Fixed overlapping x-axis ticks and graph tit…
matplotlib#1415 [Arvin, Khodier]: Fixed overlapping x-axis ticks and …
matplotlib#1415 [Arvin]: Fixed overlapping x-axis ticks and graph tit…
petehuang commented on Dec 31, 2016
I reproduced with 1.5.3:
Recommend labeling as geometry manager to mirror #1109, which is still the source of truth for this work
efiring commented on Jan 3, 2017
I think that if there is going to be a partial fix for this any time soon, it will be via using the same logic for the titles as we are using for the xlabel and ylabel. They are already taking into account the ticks and tick labels. An additional wrinkle might be the case of twinned axes; the title-positioning logic for either axes would have to check for ticks and tick labels on both axes.
jklymak commented on Mar 8, 2018
This is fixed by #9498. Removing geometry manager label, as its not necessary for this...
afvincent commented on Apr 3, 2018
Closed by #9498 (commit 7b30275).