Feature request: savefig with separated pad_inches in each direction #11764
Comments
|
Yes this is a good place to submit this idea. I don’t think it’d be a big deal to pass a four-tuple in pad_inches; I’d be against four new kwargs. Someone just has to write the PR! Edit: just to be clear: |
|
I agree that this should be a tuple and not new kwargs. Unfortunately, there's no consistent solution for the order.
If I would design something from scratch, I'd go for the CSS convention. However, that would be badly inconsistent with both conventions used in matplotib. Because of this situation, I'm unsure if we want to support a simple tuple at all. A more verbose but unambiguous alternative would be a dict with keys left, right, bottom, top. |
|
I think if you are going to do a dictionary, you might as well just do the explicit kwargs? Its kind of funny that |
Since the doc is |
|
And (matplotlib) basemap use for same reason, left, right, top, bottom. I believe that the best API would be to let |
|
I agree that tuple is not the best option here. I also agree that adding one dict is better than four new kwargs for easy of maintenance. If nobody is working on this yet, I would like to give it a try. |
|
My objection to a dictionary is the same as my objection to fontdict for text. There is no discoverability for it from the command line of IPython or Jupyter notebook. Further to fill in a dictionary properly you have to get the keys correct; is it left-pad, leftpad, pad-left, padding-left etc etc etc. At least with a kwarg you can tab-complete to get the name. A tuple on the other hand is easy to get wrong, but there are really only two sensible ways it can be organized so at most you make two guesses. I understand why we have fontdict, but I have to google the entries every time I use it and that seems like bad API to me. |
|
If we use a dict as param it should be described fully in the docstring of the respective param. I know that's not the case for fontdict. You don't get tab-completion from that, but at least you can look it up in the docstring without leaving IPython / the notebook. To that extent, a dict and a tuple are equally (non-)accessible. The dict has the advantage of being more explicit at the cost of being more verbose. I'd prefer that for rarely used options where there is no unambiguous order as in this case. Fontdict has another issue in that it's redundant to other kwargs, cf #10293. I think the situations between here and fontdict are not quite comparable. We should not mix this into the discussion here. |
|
Just registering my general disaproval of packing method arguments in dictionaries; I don't really care about this kwarg in particular, but I think its a klunky API style in general. |
Short summary of options:
Not adding the feature or supporting multiple ways are theoretically possible as well. Personally, I'm 50/50 on 1. or 3. But there were also other opinions. For a detailed discussion of the advantages/disadvantages see above. I think this is an important API decision, which should be taken deliberately. @tacaswell @efiring Can please some of the senior contributors decide on the API we want to use here. |
|
Considerations: discoverability, readability, and code complexity, all viewed with the perspective of how often a feature will be used, and by whom. Discoverability involves documentation as well as possible tab-completion. Having a large number of kwargs hurts discoverability; the docstring becomes overwhelming, and there is a problem even for tab-completion, given the present ipython default of providing a quasi-gui interface instead of listing everything. Readability is high-priority, and having the option of packing related options into a single dict kwarg aids readability, compared to an opaque tuple with non-obvious ordering. The option proposed here, allowing more detail in pad_inches, is to me low-priority; I think its use will be rare. This puts extra weight on readability (if the option is indeed worth adding at all). If this is implemented, I think options 1 (tuple) and 2 (more kwargs) is perpetuating bad API; option 3 (allowing a dict) is by far superior. |
|
Be aware, this is my first attempt at contributing to something. I propose to modify matplotlib.transforms.BboxBase.padded to return a Bbox with the points modified by values in a dict as opposed to a single value. If a single value is passed, it can be normalized via the dict.fromkeys method within BboxBase.padded as shown in master...EzraBC:master. Edit: This may be opening a can of worms, by in my opinion the most "pythonic" (though maybe not the most "matplotlib-ic") approach is to allow for as many possibilities as is easy to implement. As such, the link above now shows the BboxBase.padded method changed to allow a dict, list, tuple, or single value for the parameter p. If people more important than I disagree with this approach I am happy to pare it down. |
In addition to allowing a dict, added support for a tuple or list being passed. Also fixed some indentation and changed the dict keys to those mentioned in issue matplotlib#11764
|
Is there something against using a |
|
Instead of |
|
Just to summarize above, I think the plan is to use a dict if someone cares enough to submit a PR... |
|
I'll do it. |
|
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help! |
Uh oh!
There was an error while loading. Please reload this page.
This is just a thought I had, it would be desirable to be able to select "pad_inches" separately for the top/bottom/right/left margins.
Just to clarify, I want to be able to create my figures and whatever and only at the time of saving them to disk be able to do:
figure.savefig(filename, bbox_inches = 'tight', pad_inches_top = 0.4, pad_inches_right = 0.3)Instead of having to change the shape of the figure I'm working with or creating a new figure with the right dimensions, as the padding work in all directions at the same time. Of course it's not a critical thing but in terms of usability would be a great help.
ps. I'm not sure whether this is a good idea or whether this is the correct place to submit a feature request. Apologies in advance.
The text was updated successfully, but these errors were encountered: