-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
FIX: long titles x/ylabel layout #17222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
290c255
to
c50f062
Compare
c50f062
to
bf62cc0
Compare
lib/matplotlib/axes/_base.py
Outdated
bt = title.get_window_extent(renderer) | ||
if for_layout_only and bt.width > 0: | ||
bt.x0 = (bt.x0 + bt.x1) / 2 - 0.001 | ||
bt.x1 = bt.x0 + 0.002 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got why you do this (get a nonzero but small width bbox so that the thing doesn't get cancelled out, centered at the right place) but it's a bit... mysterious and could perhaps use a comment. Also, I think instead of picking an arbitraryish epsilon=0.001 here (and a different one for axis labels) you can use e.g. 0.5, as texts can't be less than one pixel wide anyways.
bounding box using the rules above. `.axis.Axis.get_tightbbox` gets an | ||
``ignore_label`` keyword argument, which is *None* by default, but which can | ||
also be 'x' or 'y'. These API changes are public, but are meant to be | ||
mostly used internally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could make the kwargs _for_layout_only
/_ignore_label
with a leading underscore, depending on how private you want to make them...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, thought about it, but its possible someone else would like the functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine if you want to declare this public API, I'm just not a fan of "mostly private, but not really."
lib/matplotlib/axis.py
Outdated
If ``ignore_label`` is 'x', then the width of the label is collapsed | ||
to near zero. If 'y', then the height is collapsed to near zero. This | ||
is for tight/constrained_layout to be able to ignore too-long labels | ||
when doing their layout. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps instead use the same kwarg as for Axes.get_tightbbox (to simplify documentation), i.e. for_layout_only, and then lookup self.axis_name to know which direction to ignore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the docs are pretty sparse for axis.get_tightlayout
and I wasn't sure about introspection on the axis name as a very robust way to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We look up rcparams based on axis_name, so that should be safe.
... by the way, how does that interact with polar plots?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about polar plots.... Does tight_layout work with those at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks so (e.g. try subplots(2, 2, subplot_kw=dict(projection="polar")); title("foo"); tight_layout()
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, well that code runs fine with this PR....
I am 👍 on this in principle. How terrible would it be to put the calls in attn @astrofrog @QuLogic |
You meaning someone redefined get_tightbbox and were strictly checking arguments? It’s a pretty low level function to be strict with. |
There's only one call to |
Actually, there's one PR SciTools/cartopy#1355 that would add a |
Right but the problem is if they check for the argument. If they don’t it will just be ignored and they won’t get the benefit of this PR |
36db363
to
acbd1c3
Compare
bb_yaxis = self.yaxis.get_tightbbox(renderer, ignore_label=igl) | ||
except TypeError as e: | ||
# in case downstream library has redefined axis: | ||
bb_xaxis = self.yaxis.get_tightbbox(renderer) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to warn so down-stream knows they can make this signature change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that we should warn. But now I'm wondering if passing kwords around makes sense....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative is we provide new methods for these. i.e. get_tightbbox_forlayout
that does the "right" thing. A second alternative is that the layout engines back out the correct info themselves, but that seems hard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the way this is done now is probably still the best, but other solutions welcome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you may need something similar to #12635?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't warn in #12635 so we should probably stay consistent about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think since there is nothing the end user can do about the warning, and downstream libraries don't need this feature not warning is right. It may be hard to advertise for downstream libraries, but its not a super crucial feature in my opinion, just a nicety.
f5f7580
to
474a90c
Compare
PR Summary
Closes #8201
Previously, really long titles and axes labels would kill both
tight_layout
andconstrained_layout
because they vainly would try and reduce the size of the axes to somehow make the long title "fit". However, this cannot work, so instead just ignore the dimensions these can get too long in.This leads to a few changes, but I still think is better than squishing the axes.
Before:
(tight layout had a similar check and was not applied)
After
Now the user gets the layout manager, and the title is allowed to overflow.

The only case where maybe this is dubious is just for constrained layout
Old:
Moved the undecorated axes over:
New
Just lets it look bad:
I think the latter is actually better because it tells the user that they really should fix their title, whereas before they got a mysterious message about the axes collapsing and the layout not being applied.
PR Checklist