Repository navigation
add rc param for centimeter support #1369
Description
It would be great if I could specify a figsize in centimeters. I would like to write
import matplotlib as mpl
mpl.rcParams['lengthunit'] = 'c'
figure(figsize=(12, 8))
instead of
figure(figsize=(12/2.54, 8/2.54))
I think this would be a great addition for the non-anglo-saxon world ;)
Reacted by Jan Gleixner, sveneggimann, Robert Pollak, Anand, Tim, Eron Lloyd, R Klasen, Ma_124, Daniel Burch, Sören Henning and 2 more
Reacted by Tim, Jef D, R Klasen and Ma_124
Activity
mdboom commentedon Oct 12, 2012
I agree -- requiring inches there is rather archaic. However, I don't think an rcParam is the right way to do it. I'd rather see the unit be part of the parameter, e.g.:
figsize=((12, 'cm', (8, 'cm'))
or
figsize=('12cm', '8cm')
Neither of those are perfect (more thinking needs to be done), but I think changing global state for this could be too problematic.
pwuertz commentedon Oct 12, 2012
Absolutely love the idea of using "unit-aware" objects instead of numbers for defining lengths and sizes as also stated in #1109.
@mdboom, would you be in favour of a unit-class that supports arithmetic operators like
__add__,__mul__,__sub__, etc? So for example one could definefigsize = (12*cm, 8*cm)orfigsize = (12*cm, 8*cm + 1*mm).WeatherGod commentedon Oct 12, 2012
Perhaps something like this?
http://packages.python.org/quantities/user/tutorial.html
pwuertz commentedon Oct 12, 2012
@WeatherGod, Thanks for the hint! I think I was looking for something like that for quite some time ^^. That tight integration with numpy seems nice. Is anyone imagining the plotting of such data with unit aware axis labelling too? ;)
dmcdougall commentedon Oct 12, 2012
@pwuertz I don't see the benefit of unit aware plotting/axis labelling. It requires almost no effort to append
'(cm)'or'(s)'to my x-axis label. Date/time units are useful, and already supported. What is requested here is nothing to do with unit-aware plotting but physical figure attributes. Perhaps I'm overlooking something.pwuertz commentedon Oct 12, 2012
@dmcdougall Of course this is about figure attributes and my original question to mdboom was if he is in favor of a unit class that would support arithmetic operations with ints and floats.
WeatherGod came up with that project that takes this one step further. If matplotlib adapted this package, the idea of supporting it at plot level came to my mind. Think about plotting an array of times. When you decide that you want the plot to be displayed in
usinstead ofmsyou could change that at a single position in the code. Rescaling all of the plotted data and adding the correct unit to the label would be handled automatically. Just an idea, completely off-topic.dmcdougall commentedon Oct 12, 2012
That's a fair point.
pelson commentedon Oct 16, 2012
@pwuertz : I think it is worthy of a MEP. I love the idea, and would like to see this idea get developed further and discussed before we can make a sound decision about it. Would you be willing to write a MEP?
EDIT: Fixed typo from PEP->MEP. Doh!
dmcdougall commentedon Oct 16, 2012
MEP?
pelson commentedon Oct 16, 2012
Ja ja. Sorry 😃.
pwuertz commentedon Oct 17, 2012
A MEP for general support of physical units that focuses on properties like
figsizeand discusses optional features like plotting of unit-aware data?mdboom commentedon Oct 17, 2012
I think such a MEP would be great. I see the two pieces: one for parameters like
figsize, possible font size as well) and one for unitized data. These pieces can be implemented somewhat independently (i.e. we can do one without the other), but it might be worth discussing them at the same time to contemplate some consistency between the two. We already have lots of the infrastructure for unitized data that is currently used for dates, and it would be worth investigating how that could be extended. For a long time, I've felt good docs on how to add a new unit would be very helpful -- it's not a part of the code that I personally understand very well.pelson commentedon Oct 18, 2012
Likewise. I wonder who does?
WeatherGod commentedon Oct 18, 2012
On Thursday, October 18, 2012, Phil Elson wrote:
Ben Root
pwuertz commentedon Oct 19, 2012
When I got a little more time I'd like to work on these layout managing ideas and possibly write a MEP for that. As pointed out, this would also include support for units. The question is whether to wait for that layout management project (which might be a really long time) or to implement an unit aware
figsizeoption as a more "short term" solution.8 remaining items
oscarbranson commentedon May 3, 2018
Another +1 for implementing this in rcparams. Would be great to be able to 'set and forget' metric units.
jklymak commentedon May 3, 2018
There is even a semi-abandoned MEP: #9226
I think the easiest least-painful idea would be a new method that was able to parse strings for width and height:
fig.set_size(width='15cm', height='2in'). Some will complain about hokey parsing, but...github-actions commentedon Feb 28, 2023
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!
oscargus commentedon Feb 28, 2023
This would still be useful in quite a lot of situations. The most progressed PR seems to be #12415 with quite a lot of discussions about the API.
jklymak commentedon Feb 28, 2023
I came away from that process convinced this is just they way it is. Figure size is one thing, but points and dpi are deeply embedded in the library.
wavexx commentedon Apr 7, 2025
Thanks to @timhoffm ! Small detail with huge usability improvement!