Skip to content

Add rc parameters for tight_layout parameters #5271

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 3 commits into from
Closed

Add rc parameters for tight_layout parameters #5271

wants to merge 3 commits into from

Conversation

itoijala
Copy link
Contributor

The second commit fixes what I think is a bug. Setting the parameters using fig.tight_layout(…) would not save them. Not sure about backward compatibility here.

To preserve backward compatibility, calling fig.tight_layout(pad=pad) will set h_pad = w_pad = pad. All three paddings default to 1.08 (in units of font.size).

This probably needs tests and a what's new entry, but I thought I would propose it first.

Fixes #5266.

@itoijala itoijala force-pushed the tight_layout-rc branch 2 times, most recently from 34454a6 to 8210b5c Compare October 18, 2015 19:03
@itoijala itoijala mentioned this pull request Oct 18, 2015
Closed
@mdboom
Copy link
Member

mdboom commented Oct 19, 2015

Cc: @leejjoon as a tight layout expert

tacaswell
tacaswell reviewed Oct 25, 2015
View reviewed changes
lib/matplotlib/figure.py
@@ -1728,6 +1730,10 @@ def tight_layout(self, renderer=None, pad=1.08, h_pad=None,
rect=rect)

self.subplots_adjust(**kwargs)
self._tight_parameters.update(
(k, v) for k, v in six.iteritems(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just do this with a tuple of tuples (('pad', pad), ('h_pad', h_pad)...). I think that will be a bit more readable and get rid of the six usage.

@itoijala
Copy link
Contributor Author

I'll just use this spot to ask about the tight_layout API.

Currently I think the API is not very intuitive. Problems:

  • set_tight_layout(False) forgets current parameters.
  • tight_layout cannot be used to iteratively update the parameters, since the ones not given in a call are set to the default values. Something like fig.tight_layout(h_pad=5) fig.tight_layout(w_pad=2) does not do the intuitive thing.
  • There is no way to retrieve the current parameters.
  • pad and h_pad, w_pad have quite different uses. The defaulting of the others to pad is not intuitive. A common(?) use case is to eliminate white borders around the plot using fig.tight_layout(pad=0) which currently also sets the padding between subplots to 0.

I would prefer something like:

  • figure.__init__: initialise _tight_parameters to rc values (should add rc values for rect also). This is the only place in the figure API that the parameters are set to default values.
  • figure.set_tight_layout: set all parameters at once, should also perform the update (call fig.tight_layout with no parameters). Should remember old parameters for when the user returns to tight_layout using fig.set_tight_layout(True).
  • figure.tight_layout: update _tight_parameters with given values (None = don't change). Update figure.
  • h_pad and w_pad should not default to pad.
  • Add a way to get the current parameters. The name get_tight_layout is of course already taken.
  • plt.tight_layout should just forward to fig.tight_layout like it does now.
  • The lower level functions affected by this PR can continue to work like they do with this PR (get defaults from rc), though figure will always call them with all parameters set.

This would naturally not be a backward compatible change.

@itoijala
remove trailing spaces
cd33110
@itoijala
update figure tight_layout parameters in tight_layout()
8364231
@itoijala
add rc parameters for tight_layout parameters
722721e 
To preserve backwards compatibility, calling fig.tight_layout(pad=pad)
will set h_pad=w_pad=pad.
All three paddings default to 1.08 (in units of font.size).
@tacaswell tacaswell modified the milestones: proposed next point release (2.1), next major release (2.0) Nov 24, 2015
@tacaswell
Copy link
Member

@mdboom This might be relevant to the bounding box on the outward ticks.

@tacaswell tacaswell closed this Jan 25, 2016
@tacaswell tacaswell reopened this Jan 25, 2016
@efiring
Copy link
Member

efiring commented Apr 11, 2016

The effort here is appreciated, but I am wondering: given that tight_layout is a hack workaround, does it make sense to keep adding to it? Is there a realistic prospect of being able to replace it with a layout engine any time soon?

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.0 (style change major release) Apr 11, 2016
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Sep 24, 2017
@jklymak
Copy link
Member

jklymak commented May 8, 2018

I'm going to close as not having traction. Feel free to re-open if someone would like to re-champion...

@jklymak jklymak closed this May 8, 2018
@story645 story645 removed this from the future releases milestone Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add an rc file setting for the pad parameter of tight_layout
7 participants
@itoijala @mdboom @tacaswell @efiring @jklymak @QuLogic @story645