Move title up if x-axis is on the top of the figure #9498

jklymak · 2017-10-21T04:22:09Z

PR Summary

It the x-axis is at the top of the axes, then the title is actually rendered in the middle of the axis labels.

This version works no matter the size of the figure (unlike the version that @tacaswell was 50/50 on below), though tight_layout (or #9082) are needed to get the title to show with the default axes positions...

import matplotlib.pyplot as plt

fig, ax = plt.subplots(tight_layout=True)

ax.xaxis.tick_top()
ax.xaxis.set_label_position('top')

ax.set_xlabel('Xlabel')
ax.set_title('Title')

Before:

After:

The title position is changed at draw time based on the top of the x-axis or the xlabel. If the user has manually placed the title (ax.title.get_position((x,y))) then the title won't be moved unless they happened to place it at y=1.0. This degeneracy can be fixed by setting y=1.001. (This very slight annoyance avoids having to make a new method to set the title that would not be backward compatible).

This is a fix to #1415

Note: based on axis._update_label_position...

PR Checklist

Has Pytest style unit tests
Code is PEP 8 compliant
New features are documented, with examples if plot related
Documentation is sphinx and numpydoc compliant
Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)

tacaswell · 2017-10-21T17:44:32Z

I am 50/50 on this. This is a simple fix to a long standing bug, but it is only partial (as you explain) and hysteresis in APIs in one of the things that frustrates users the most.

This seems like something that #9082 should take care of? If the goal is to get that in for 2.2, I don't think we should merge this.

jklymak · 2017-10-21T20:21:01Z

@tacaswell #9082 is limited to the same functionality as tight_layout right now in that it only operates at the axes level and above, and not inside axes. So it can’t handle this case

Not to say it couldn’t handle this case with more work. But there is a bit of a conceptual leap from figure space to axes space. Axes layout can almost be done as a separate pass from figure layout.

jklymak · 2017-10-21T20:30:15Z

Btw totally fine if this isn’t accepted. If it often requires manual intervention anyways perhaps folks should just set manually. I’ll poke around for a good part of the tutorials to indicate how that can be done.

jklymak · 2017-10-21T23:39:44Z

OK, closing. I'm going to copy what xlabel and ylabel do and move the title just above whatever is at the top of the upper spine. It has some confusing transforms, but I think its totally doable.

jklymak · 2017-10-22T04:20:42Z

Re-opening! Please see new description above.

jklymak · 2017-10-22T04:29:49Z

@tacaswell Just to carry on the discussion above: the new solution is basically what a geometry manager would do anyway: put the title above the xlabel. I'd argue that a constraint manager isn't particularly needed for such a simple task. Now, if you wanted all the titles for different subplots to line up that is when a more expansive geometry manager would be helpful.

jklymak · 2018-01-29T15:55:52Z

rebase

jklymak · 2018-02-02T19:18:42Z

@efiring changes broke this, but I'm sure they are fixable, just will take a bit of work...

afvincent · 2018-02-02T19:46:09Z

Well, I may be naive, but is it a lot more complicated than replacing

axs = [self] + self._twinx_axes + self._twiny_axes

by

axs = self._twinned_axes.get_siblings(self)
# NB:
#
# In [2]: ax._twinned_axes.get_siblings?
# Signature: ax._twinned_axes.get_siblings(a)
# Docstring: Returns all of the items joined with *a*, including itself.

as well as in the tests

self._twinx_axes.append(ax2)
# and
self._twiny_axes.append(ax2)

by

self._twinned_axes.join(self, ax2)

?

afvincent · 2018-02-02T22:01:13Z

With the following patch, the new tests are passing locally. I have one remaining failure in all the tests related to axes, about one of the boxplot pictures, but it looks like it is failure for a few pixel that are a bit off.

From add5ce3c1a078164657e4d8b9dd58eda68f7275b Mon Sep 17 00:00:00 2001
From: "Adrien F. Vincent" <vincent.adrien@gmail.com>
Date: Fri, 2 Feb 2018 13:56:14 -0800
Subject: [PATCH 2/2] use new privates attributes about twins

---
 lib/matplotlib/axes/_base.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/matplotlib/axes/_base.py b/lib/matplotlib/axes/_base.py
index da85db0d5..15cc47c96 100644
--- a/lib/matplotlib/axes/_base.py
+++ b/lib/matplotlib/axes/_base.py
@@ -2507,7 +2507,7 @@ class _AxesBase(martist.Artist):
             x, y0 = title.get_position()
             y = 1.0
             # need to check all our twins too...
-            axs = [self] + self._twinx_axes + self._twiny_axes
+            axs = self._twinned_axes.get_siblings(self)
 
             for ax in axs:
                 try:
@@ -4243,7 +4243,7 @@ class _AxesBase(martist.Artist):
         self.yaxis.tick_left()
         ax2.xaxis.set_visible(False)
         ax2.patch.set_visible(False)
-        self._twinx_axes.append(ax2)
+        self._twinned_axes.join(self, ax2)
         return ax2
 
     def twiny(self):
@@ -4273,7 +4273,7 @@ class _AxesBase(martist.Artist):
         self.xaxis.tick_bottom()
         ax2.yaxis.set_visible(False)
         ax2.patch.set_visible(False)
-        self._twiny_axes.append(ax2)
+        self._twinned_axes.join(self, ax2)
         return ax2
 
     def get_shared_x_axes(self):
-- 
2.14.3

I am not totally confident on how to properly push that fix against the current PR branch and avoid breaking @jklymak stuff :/.

jklymak · 2018-02-02T22:04:55Z

Yeah, I don't know how to force-push either ;-) Thanks for the patch, I'll check it in by tomorrow....

jklymak · 2018-03-23T18:14:14Z

recycling. SOmething funny w/ CI

jklymak · 2018-03-23T20:36:00Z

Added test for no-xlabel (thanks @afvincent, per gitter). Fixed bug for that case as well (typo)

jklymak · 2018-03-31T01:41:15Z

ping @afvincent - this seem OK to you now? Thanks!

afvincent

Disclaimer: I am way too out of my depth to judge the logging part...

Otherwise, apart from a few typos (I think), a comment about the semantic of y1 vs ymax in boundary boxes, and a few other remarks mainly made by curiosity, this starts to look good to me :).

afvincent · 2018-04-03T01:09:48Z

doc/users/next_whats_new/title_will_not_overlap_xaxis.rst

+
+Previously the axes title had to be moved manually if an xaxis overlapped
+(usually when the xaxis was put on the top of the axes).  The title can
+still be placed manaully.


afvincent · 2018-04-03T01:20:04Z

lib/matplotlib/axes/_base.py

+                    if (ax.xaxis.get_label_position() == 'top'
+                            or ax.xaxis.get_ticks_position() == 'top'):
+                        bb = ax.xaxis.get_tightbbox(renderer)
+                        top = bb.y1


Should it not be top = bb.ymax rather than top = bb.y1? That is a very genuine question, because I am not that used to play with boundary boxes and the docstring of y1 reads

:attr:`y1` is the second of the pair of *y* coordinates that define the bounding box. :attr:`y1` is not guaranteed to be greater than :attr:`y0`. If you require that, use :attr:`ymax`.

Oh, cool, I didn't know that.

Do we prefer to stay with top = bb.y1, while it actually means top = bb.ymax (if I correctly understood the process)? I guess that in 99.99% of the cases here, it will be equivalent, but the semantic of the latter might be clearer, right? (I have no strong feelings about any of the two options)

afvincent · 2018-04-03T01:22:16Z

lib/matplotlib/axes/_base.py

+                        # in __init__: titleOffsetTrans
+                        yn = self.transAxes.inverted().transform((0., top))[1]
+                        y = max(y, yn)
+                except AttributeError:


By curiosity, when is an AttributeError likely to occur? In a case where an empty boundary box would be returned (I mean a case where bb would be None)?

Ummm, I forget why exactly, but I think it was possible for ax to not have an xaxis property. I can check what test fails if important.

Fair enough for me, no worry ;).

afvincent · 2018-04-03T01:31:48Z

lib/matplotlib/axes/_base.py

+        if self._autotitlepos is None:
+            for title in titles:
+                x, y = title.get_position()
+                if not np.isclose(y, 1.0):


Very dumb question incoming 🐑... With this implementation, there is no way to pin the title y-position at 1.0 and still avoid the auto title positioning, is there not? But in case anybody would like to do so (for whichever good or bad reason ^^), I guess that a reasonable workaround would be to pin the title y-position at something like 1.001, right?

Thats correct. I could do something like find the first call that sets the title at 1.0 and then flag future calls to set_position as being "pinned", even if it is y=1.0. But setting to 1.01 will give the same result.

IMHO, setting y=1.001 is a good enough solution. Maybe it should be put in the “what's new” entry (just for the workaround to be documented somewhere)?

afvincent · 2018-04-03T01:35:35Z

lib/matplotlib/axes/_base.py

@@ -2594,6 +2647,7 @@ def draw(self, renderer=None, inframe=False):
            renderer.stop_rasterizing()

        mimage._draw_list_compositing_images(renderer, self, artists)
+        self._update_title_position(renderer)


Why exactly is it called a second time in draw (first call at l. 2598)?

Seems to work w/o the second call. Good catch!

afvincent · 2018-04-03T01:38:47Z

lib/matplotlib/tests/test_axes.py

+
+
+def test_title_xticks_top():
+    # Test that title stays put if we set it manually


Is this comment/docstring correct?

afvincent · 2018-04-03T01:42:41Z

lib/matplotlib/tests/test_axes.py

+    ax.xaxis.set_ticks_position('top')
+    ax.set_title('xlabel top')
+    fig.canvas.draw()
+    assert ax.title.get_position()[1] > 1.04


Just by curiosity, is 1.04 an arbitrary threshold value that was empirically found? (I would have genuinely expected something like > 1.0, or maybe > 1.01 to avoid numerical precision issues 🐑 )

1.04 was just large enough to definitely not be at 1.0. No good reason for it.

Fair enough, I just wanted to be sure that I was not missing something.

afvincent

A couple remaining/new remarks, but otherwise this looks good (AFAICT) :).

afvincent · 2018-04-03T03:46:31Z

doc/users/next_whats_new/title_will_not_overlap_xaxis.rst

+Previously the axes title had to be moved manually if an xaxis overlapped
+(usually when the xaxis was put on the top of the axes).  The title can
+still be placed manually.  However, titles that need to be moved are
+at ``y=1.0``,  so manualy placing at 1.0 will be moved, so if the title


I guess that 'manualy' is a typo. Besides, the whole sentence seems quite long to me with many complements: I wonder if this makes it hard to read or not (as a French native speaker, I am a bit too biased to judge long sentences with complements of complements...). Would something like

However, titles that need to be moved are at ``y=1.0``, so manual placing at 1.0 will be moved. If the title is to be placed at 1.0, it should be set to something near 1.0, like 1.001.

be OK too?

Agreed. Changed to be more verbose, and hopefully more clear.

Previously an axes title had to be moved manually if an xaxis overlapped (usually when the xaxis was put on the top of the axes). Now, the title will be automatically moved above the xaxis and its decorators (including the xlabel) if they are at the top. If desired, the title can still be placed manually. There is a slight kludge; the algorithm checks if the y-position of the title is 1.0 (the default), and moves if it is. If the user places the title in the default location (i.e. ``ax.title.set_position(0.5, 1.0)``), the title will still be moved above the x-axis. If the user wants to avoid this, they can specify a number that is close (i.e. ``ax.title.set_position(0.5, 1.01)``) and the title will not be moved via this algorithm.

afvincent · 2018-04-03T03:52:19Z

lib/matplotlib/axes/_base.py

+                    if (ax.xaxis.get_label_position() == 'top'
+                            or ax.xaxis.get_ticks_position() == 'top'):
+                        bb = ax.xaxis.get_tightbbox(renderer)
+                        top = bb.y1


Do we prefer to stay with top = bb.y1, while it actually means top = bb.ymax (if I correctly understood the process)? I guess that in 99.99% of the cases here, it will be equivalent, but the semantic of the latter might be clearer, right? (I have no strong feelings about any of the two options)

afvincent

LGTM :)! I'll let the joyce of hitting the green button to somebody more comfortable than I am with the merging/backporting process ^^.

A slight comment on the “what's new” (which is BTW definitively clearer than before), but I guess it is more an English issue than anything else: is there a slight difference in meaning between “xaxis” and “x-axis”? If there is not, then there are other uses that might not be totally consistent (e.g. “xlabel”). But I would not block this PR any longer just for this.

jklymak · 2018-04-03T17:10:40Z

"xaxis" was made consistent in the whats-new. Yes "xaxis" is a bit illiterate, but it'll make it easier to find in the rest of the docs.

This won't be backported, so all you do is hit the little green button if you are happy 😉 It only gets complicated if you forget to milestone the PR and it should be backported, or if you want to squash a pile of commits. But neither is the case here.

afvincent · 2018-04-03T17:19:20Z

Thanks for the explanations. Then just waiting for the CI to finish running (everything was green before but this should be over in ~ 5 minutes anyway...).

jklymak force-pushed the fixtitle branch from 9f3879a to 90e65fe Compare October 21, 2017 04:23

tacaswell added this to the v2.2 milestone Oct 21, 2017

jklymak closed this Oct 21, 2017

jklymak reopened this Oct 22, 2017

jklymak force-pushed the fixtitle branch 3 times, most recently from c28f1f4 to 7c9ab29 Compare October 22, 2017 21:16

jklymak changed the title ~~Move title up if x-axis is on the top of the figure~~ MRG: Move title up if x-axis is on the top of the figure Nov 1, 2017

jklymak mentioned this pull request Nov 1, 2017

Align x and y labels between axes #9652

Merged

9 tasks

jklymak requested review from dstansby and efiring November 2, 2017 21:55

jklymak force-pushed the fixtitle branch from 7c9ab29 to ab50f6b Compare December 2, 2017 15:48

jklymak added the status: needs review label Dec 2, 2017

jklymak force-pushed the fixtitle branch from ab50f6b to e0d7e72 Compare January 29, 2018 15:55

jklymak mentioned this pull request Feb 2, 2018

Add ytick label right/left properties in matplotlibrc #10306

Merged

jklymak added status: needs revision and removed status: needs review labels Feb 2, 2018

jklymak removed request for efiring and dstansby February 2, 2018 19:18

jklymak force-pushed the fixtitle branch 2 times, most recently from de80a64 to ea54c71 Compare March 23, 2018 18:04

jklymak removed the status: work in progress label Mar 23, 2018

jklymak closed this Mar 23, 2018

jklymak reopened this Mar 23, 2018

jklymak force-pushed the fixtitle branch from ea54c71 to 69f704b Compare March 23, 2018 18:15

jklymak added the status: needs review label Mar 23, 2018

afvincent reviewed Apr 3, 2018

View reviewed changes

jklymak force-pushed the fixtitle branch 4 times, most recently from 456ad43 to 1675d25 Compare April 3, 2018 02:55

ENH: Move title if x-axis is on the top of the figure

a0f10b9

jklymak force-pushed the fixtitle branch from 1675d25 to a0f10b9 Compare April 3, 2018 02:56

afvincent reviewed Apr 3, 2018

View reviewed changes

afvincent approved these changes Apr 3, 2018

View reviewed changes

DOC: Whats new entry for title moving above xaxis

c2db893

jklymak force-pushed the fixtitle branch from f7af85e to c2db893 Compare April 3, 2018 17:06

afvincent merged commit 7b30275 into matplotlib:master Apr 3, 2018

jklymak deleted the fixtitle branch April 3, 2018 17:38

jklymak removed the status: needs review label Apr 3, 2018

jklymak mentioned this pull request Jun 22, 2018

Layout managers have problems with titles containing MathText #11468

Closed

This was referenced Mar 22, 2019

title doesn't move for ticklables.... #13735

Closed

FIX: make title move above ticklabels #13741

Merged

jklymak mentioned this pull request Mar 21, 2020

FIX: turn off title autopos if pad is set #16862

Closed

6 tasks



		def test_title_xticks_top():
		# Test that title stays put if we set it manually

Move title up if x-axis is on the top of the figure #9498

Move title up if x-axis is on the top of the figure #9498

Conversation

jklymak commented Oct 21, 2017 • edited Loading

PR Summary

PR Checklist

tacaswell commented Oct 21, 2017

jklymak commented Oct 21, 2017

jklymak commented Oct 21, 2017

jklymak commented Oct 21, 2017

jklymak commented Oct 22, 2017 • edited Loading

jklymak commented Oct 22, 2017

jklymak commented Jan 29, 2018

jklymak commented Feb 2, 2018

afvincent commented Feb 2, 2018

afvincent commented Feb 2, 2018

jklymak commented Feb 2, 2018

jklymak commented Mar 23, 2018

jklymak commented Mar 23, 2018

jklymak commented Mar 31, 2018

afvincent left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afvincent left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afvincent left a comment

Choose a reason for hiding this comment

jklymak commented Apr 3, 2018

afvincent commented Apr 3, 2018

jklymak commented Oct 21, 2017 •

edited

Loading

jklymak commented Oct 22, 2017 •

edited

Loading