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

jklymak · 2020-03-21T15:05:43Z

PR Summary

When title autopositioning was put in #9498 it was overlooked that the user may manually specify the pad, and hence autopositioning should not take place.

import matplotlib.pyplot as plt

fig, (ax1, ax2) = plt.subplots(ncols=2)
for ax in (ax1, ax2):
    ax.set_title(f"Title 1", pad=-20)

ax1.tick_params(labelbottom=False)

plt.show()

Now yields

Similar behaviour is respected for rcParam('axes.titlepad') which now defaults to None

Note: classic style (used in most tests) sets axes.titlepad = 5, so there were a couple of places in test_axes.py that needed to manually set it to "None".

There were two tests in test_tightlayout.py that failed with a pixel offset in the data line being drawn. I think this is a pixel snapping issue and elided it by setting the tolerance higher rather than trying to hunt this down. However, if folks really want it fixed, it probably means re-doing the image test (and probably making them work with a less fussy data set).

PR Checklist

Has Pytest style unit tests
Code is Flake 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)
Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

ImportanceOfBeingErnest · 2020-03-21T17:34:54Z

What should happen if the user specifies the padding in the rc paramters, i.e. plt.rcParams['axes.titlepad'] = -20 ?

jklymak · 2020-03-21T17:48:13Z

It would still auto position.

I guess I think the pad of 6 is a mistake, and it should be a pad of None, and resolved to 6 when needed. Thats a bit more of a change, but I don't think its too much work.

jklymak · 2020-03-22T01:15:07Z

Looked into this.

Its pretty easy to just change the title's y to be above the top decorations and not have any logic attached to pad at all. And that works fine.

However, that gives perhaps unexpected results if there are top decorators.

fig, ax = plt.subplots()
ax.set_title(f"Pad = -20", pad=-20)
ax.tick_params(axis="x",
               bottom=True, top=True, labelbottom=True, labeltop=True)
plt.show()

So here, the position has been moved to > 1.0 to make room for the axes, but the user has set pad to a negative number. I guess I think thats OK, its not too hard to get what they want...

ax.set_title(f"Pad = -20", pad=-20, y=1)

jklymak · 2020-03-22T02:45:14Z

OK. that breaks the fixes we put in if the title has a big overlap i.e. due to a subscript, which we all thought was a useful thing to do. #11502

I think the way forward is assume that if the user has axes.titlepad set then they don't want the auto-adjust behaviour. Folks who want the auto adjust can take what default we given time (autoadjust+6 points). That means changing the default for axes.titlepad to None, but I think thats straightforward.

jklymak · 2020-03-22T16:29:39Z

I think test failures are because the classic style sets titlepad=5. I think thats fine. If you use classic you won't get automatic title positioning.

jklymak · 2020-04-03T16:15:47Z

I think this is ready for review now. Please see updated commentary above.

QuLogic

I'm not totally sure that pad implies no-auto positioning.

QuLogic · 2020-04-04T02:54:36Z

doc/api/next_api_changes/behaviour.rst

-the lines and markers defaulting to whatever the first color in the color cycle was in the case of 
-multiple plot calls. 
+Previously setting the *ecolor* would turn off automatic color cycling for the plot, leading to the
+the lines and markers defaulting to whatever the first color in the color cycle was in the case of


Since you changed the line, there's a double 'the' that could be de-duplicated.

Hmmmm, I didn't mean to change this line...

QuLogic · 2020-04-04T02:55:29Z

doc/api/next_api_changes/behaviour.rst

+Since 3.0, Axes titles are automatically repositioned, primarily to avoid
+xlabels or xticks at the top of the axes.  The user could turn this
+off using the optional *y* argument to `~.Axes.set_title`).  However, that
+made it impossible to manually set the *pad* argument;  Now *pad* defaults to


No need for a semicolon. Also, it should be "with y", no?

Suggested change

made it impossible to manually set the *pad* argument; Now *pad* defaults to

made it impossible to manually set the *pad* argument without also setting the *y* argument. Now *pad* defaults to

QuLogic · 2020-04-04T03:03:31Z

lib/matplotlib/tests/test_axes.py

+    # test that if we pad, then the title does not autopos
+
+    fig, ax = plt.subplots()
+    ax.set_title(f"Title 1", pad=-20)


Don't need the f-string.

QuLogic · 2020-04-04T03:06:47Z

lib/matplotlib/tests/test_tightlayout.py

@@ -19,7 +19,7 @@ def example_plot(ax, fontsize=12):
    ax.set_title('Title', fontsize=fontsize)


-@image_comparison(['tight_layout1'])
+@image_comparison(['tight_layout1'], tol=1.87)


Do you need to increase the tolerance, or can you not set the rcParam like the other test?

No, its really strange - the whole figure is the same except for the blue line.

This was the macOS failure with new Ghostscript? So this can now be rebased out.

I don't think so, but maybe...

jklymak · 2020-04-04T03:19:05Z

@QuLogic WRT the padding being set, I think the choices are:

if ytop is the bounding box of the axes and all its decorators,

then pad could be relative to ytop (which is current behaviour on master)
if pad is not None, then pad is relative to y=1; if pad is None, then title is placed at y+6pts (proposed behaviour here)
if pad<0 pad could be relative to y=1, and pad > 0 relative to ytop.

The user in the original issue clearly wanted 2 or 3.

Automatic title repositioning is now suppressed if the title padding is set to a non-None value by the user (either in the pad kwarg, or the rcParam axes.titlepad)

tacaswell · 2020-04-13T22:06:45Z

lib/matplotlib/tests/test_axes.py

@@ -5532,13 +5534,26 @@ def test_title_xticks_top():
 def test_title_xticks_top_both():
    # Test that title moves if xticks on top of axes.
    fig, ax = plt.subplots()
+    # set to the new default (from 5, which will suppress title reposition)
+    mpl.rcParams['axes.titlepad'] = None


Would it be better to switch these to use the new default style?

I dunno, I admit to being thorough confused as to what style is default for the tests, versus which need to have the style specified somehow. It seems that all the tests are run classic? But I don't know how to change a new test to use default if its not an image test.

tacaswell · 2020-04-13T22:19:23Z

I'm not totally sure that pad implies no-auto positioning.

I think the argument is that both y and pad can cause the next to shift vertically so we have a degeneracy. If the user gives us neither, we can safely "do the right thing" and auto-adjust. If they give us either, then we should revert back to the old fixed behavior to maintain back compatibility.

The down side of pad -> no auto means we have no knob to adjust our auto behavior. Exploiting this degeneracy for "fine tuning" seems useful (if I am understanding this right). Given that this was changed in 3.0 and this is the first bug report about this, we may have picked up users who are now relying on the master branch behavior.

I am +.5 on this, but that is a pretty soft position.

Do we also auto-adjust the xlabels?

jklymak · 2020-04-13T23:06:53Z

@tacaswell good point:

import matplotlib.pyplot as plt

fig, axs = plt.subplots(1, 2, constrained_layout=True)
axs[0].set_ylabel('Hi: labelpad=-4', labelpad=-4)
axs[1].set_ylabel('Hi: labelpad=+4', labelpad=4)

plt.show()

returns

jklymak · 2020-04-13T23:11:13Z

So, based on that, I'd argue titlepad should be changed to be relative to whatever y the auhopositioning chooses (just like for the xlabel's pad)

jklymak · 2020-04-13T23:45:03Z

OK, looked into this some more:

We could change this to make the baseline of the title relative to the top of the axes decorators plus the pad (of 6 pts). And then negative pads would be allowed.

We didn't do this because of folks doing big math text in their title and complaining that it overhung the decorators. So before the change:

Before

And then we changed it to automatically do:

After:

But the way we do that is to see if the bbox for the title overhangs the axes and its decorators. If it does, we move it up.

That is great, but if clearly is incompatible with a negative pad. Note that positive pads work fine.

So, not sure what to do here. Tempted to keep the autopositioning behaviour and ask folks to just set y=0.0001 if they don't want the autopositioning.

jklymak · 2020-04-13T23:50:34Z

So, perhaps the solution is a new rcParam: axes.titley that defaults to None for autopositioning, and otherwise doesn't do autopositioning?

jklymak · 2020-04-14T04:31:26Z

So I think #17127 is a better way forward, but can re-open this if not...

jklymak added this to the v3.3.0 milestone Mar 21, 2020

jklymak force-pushed the fix-pad-title branch from 32e67ef to e960b5b Compare March 22, 2020 03:02

jklymak force-pushed the fix-pad-title branch from e960b5b to d00c7e0 Compare March 23, 2020 02:12

jklymak force-pushed the fix-pad-title branch 2 times, most recently from e4f7360 to 2abccf8 Compare April 3, 2020 16:11

jklymak force-pushed the fix-pad-title branch 2 times, most recently from b5a2198 to d65fa16 Compare April 3, 2020 22:35

QuLogic reviewed Apr 4, 2020

View reviewed changes

jklymak force-pushed the fix-pad-title branch from d65fa16 to b35cc73 Compare April 4, 2020 21:15

jklymak force-pushed the fix-pad-title branch from b35cc73 to ff401e3 Compare April 13, 2020 21:41

ENH/FIX: Don't auto reposition axes if axes.titlepad not None

c88e7c8

Automatic title repositioning is now suppressed if the title padding is set to a non-None value by the user (either in the pad kwarg, or the rcParam axes.titlepad)

jklymak force-pushed the fix-pad-title branch from ff401e3 to c88e7c8 Compare April 13, 2020 21:43

tacaswell reviewed Apr 13, 2020

View reviewed changes

jklymak marked this pull request as draft April 13, 2020 23:11

jklymak added 3 commits April 13, 2020 16:20

FIX: do this with offset from top

a4a4570

TST

edf17a8

DOC

9271fe6

jklymak mentioned this pull request Apr 14, 2020

ENH: allow title autopositioning to be turned off #17127

Merged

6 tasks

jklymak closed this Apr 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

jklymak commented Mar 21, 2020 •

edited

Loading

ImportanceOfBeingErnest commented Mar 21, 2020

jklymak commented Mar 21, 2020

jklymak commented Mar 22, 2020

jklymak commented Mar 22, 2020

jklymak commented Mar 22, 2020

jklymak commented Apr 3, 2020

QuLogic left a comment

QuLogic Apr 4, 2020

jklymak Apr 4, 2020

QuLogic Apr 4, 2020

QuLogic Apr 4, 2020

QuLogic Apr 4, 2020

jklymak Apr 4, 2020

QuLogic Apr 13, 2020

jklymak Apr 13, 2020

jklymak commented Apr 4, 2020

tacaswell Apr 13, 2020

jklymak Apr 13, 2020

tacaswell commented Apr 13, 2020

jklymak commented Apr 13, 2020

jklymak commented Apr 13, 2020

jklymak commented Apr 13, 2020 •

edited

Loading

jklymak commented Apr 13, 2020

jklymak commented Apr 14, 2020

	made it impossible to manually set the pad argument; Now pad defaults to
	made it impossible to manually set the pad argument without also setting the y argument. Now pad defaults to

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

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

Conversation

jklymak commented Mar 21, 2020 • edited Loading

PR Summary

PR Checklist

ImportanceOfBeingErnest commented Mar 21, 2020

jklymak commented Mar 21, 2020

jklymak commented Mar 22, 2020

jklymak commented Mar 22, 2020

jklymak commented Mar 22, 2020

jklymak commented Apr 3, 2020

QuLogic 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

jklymak commented Apr 4, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tacaswell commented Apr 13, 2020

jklymak commented Apr 13, 2020

jklymak commented Apr 13, 2020

jklymak commented Apr 13, 2020 • edited Loading

Before

After:

jklymak commented Apr 13, 2020

jklymak commented Apr 14, 2020

jklymak commented Mar 21, 2020 •

edited

Loading

jklymak commented Apr 13, 2020 •

edited

Loading