Hi! I really enjoy using matplotlib but something is strange with the units used for the figure size. It seems that it must be in inches? (I'm thinking of the figure.figsize value in matplotlibrc, for instance). Of course if one knows how long an inch is (apparently 2.5 cm) it's not difficult to convert a value in mm or cm to inches but most people around here (Europe) have never used inches in their life. I believe that centimetres (or millimetres) should be the default unit for all lengths because it is familiar to everybody... as far as I know. Then you might also allow the customary local units of various countries. If you really want to only use inches then i think that you should specify that an inch corresponds to 2.5 cm wherever a value in inches is needed. Most users of matplotlib have no clue as to how long an inch is. I'd be willing to help on that matter if you all agree that such a change would be a good idea. Thanks!! == Olivier
Coincidentally, I was just thinking about this a couple days ago, when reviewing the units kwarg of the colorbar. I decided then that adding a cm option just wasn't worth even the small amount of extra code; inches are fairly deeply embedded, as witness the standard "dpi" way of specifying pixel size on output devices. I do understand the rationale; many of us in the US would have preferred if the US had continued with the transition to metric units instead of backing off. For mpl right now, however, I don't think it is worthwhile to add the extra complexity, no matter how small it may seem, of a general cm option, or a great number of docstring additions saying "There are 2.54 cm per inch." Somewhere along the line, it may make sense to support the metric system better in mpl. Eric Olivier Verdier wrote: > Hi! > > > I really enjoy using matplotlib but something is strange with the units > used for the figure size. It seems that it must be in inches? (I'm > thinking of the figure.figsize value in matplotlibrc, for instance). > > > Of course if one knows how long an inch is (apparently 2.5 cm) it's not > difficult to convert a value in mm or cm to inches but most people > around here (Europe) have never used inches in their life. > > > I believe that centimetres (or millimetres) should be the default unit > for all lengths because it is familiar to everybody... as far as I know. > > > Then you might also allow the customary local units of various > countries. If you really want to only use inches then i think that you > should specify that an inch corresponds to 2.5 cm wherever a value in > inches is needed. Most users of matplotlib have no clue as to how long > an inch is. > > > I'd be willing to help on that matter if you all agree that such a > change would be a good idea. > > > Thanks!! > > > == Olivier > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
I agree that we have to remain in inches internally. Non-metric units are pretty ingrained in the printing world (not just in matplotlib) -- Postscript, for example, always does page sizes in inches, even if you're using a "metric" page size like A4. The current definition of a point as 1/72 of a modern inch is also fairly standard worldwide. Even printers in France, for example, are spec'd in points par pouce (ppp), which is exactly equivalent to dots per inch (dpi). However, that's just an implementation detail we have to stick with. Matplotlib has Figure.get/set_size_inches now. What's to stop us from adding get/set_size_cm, and doing the conversion right there? There might be some rounding error, but I don't think it matters in this particular case. We would probably also want to add a "figsize_cm" kwarg to the Figure constructor (which would be mutually exclusive to "figsize"). What do you think? Cheers, Mike Eric Firing wrote: > Coincidentally, I was just thinking about this a couple days ago, when > reviewing the units kwarg of the colorbar. I decided then that adding a > cm option just wasn't worth even the small amount of extra code; inches > are fairly deeply embedded, as witness the standard "dpi" way of > specifying pixel size on output devices. > > I do understand the rationale; many of us in the US would have preferred > if the US had continued with the transition to metric units instead of > backing off. For mpl right now, however, I don't think it is worthwhile > to add the extra complexity, no matter how small it may seem, of a > general cm option, or a great number of docstring additions saying > "There are 2.54 cm per inch." > > Somewhere along the line, it may make sense to support the metric system > better in mpl. > > Eric > > Olivier Verdier wrote: >> Hi! >> >> >> I really enjoy using matplotlib but something is strange with the units >> used for the figure size. It seems that it must be in inches? (I'm >> thinking of the figure.figsize value in matplotlibrc, for instance). >> >> >> Of course if one knows how long an inch is (apparently 2.5 cm) it's not >> difficult to convert a value in mm or cm to inches but most people >> around here (Europe) have never used inches in their life. >> >> >> I believe that centimetres (or millimetres) should be the default unit >> for all lengths because it is familiar to everybody... as far as I know. >> >> >> Then you might also allow the customary local units of various >> countries. If you really want to only use inches then i think that you >> should specify that an inch corresponds to 2.5 cm wherever a value in >> inches is needed. Most users of matplotlib have no clue as to how long >> an inch is. >> >> >> I'd be willing to help on that matter if you all agree that such a >> change would be a good idea. >> >> >> Thanks!! >> >> >> == Olivier >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Eric Firing wrote: > Somewhere along the line, it may make sense to support the metric system > better in mpl. It seems to me that the "right" way to do this is to use some sort of "array-with_units" class. Then what MPL would except was a "length", and the user would specify what they want. i.e: figure(figsize = units.inches((8.5,11)) rather than: figure(figsize = (8.5, 11), units=inches) Though this does make for more typing. With the later way, a system default for units could be used more easily. I really want a unit class like this for other stuff anyway. -- just thinking in email.... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
This is much worse than I thought. The "inch" unit is used in many places in matplotlib. In particular in `figure` and `savefig`. Please, please consider allowing other units. Let me emphasise this once more: in Europe, and, I believe in most places around the world, one NEVER uses inches. Neither in engineering nor, i think, in typography. For most people "inch" is basically an unusual measure of how big screens are. I'm not kidding. Same for dpi, it's a specific measurement of a resolution but nobody thinks of it as a number of pixels per inches. I have nothing against an internal use of inches inside matplotlib but please consider allowing other units for all kinds of interfaces with the user! The best choice in my opinion would be to have a unit preference in the .matplotlibrc file. This unit could be, say, `inch` or `cm` (or mm). Then any length would be expressed using this unit of length. That seems simple enough, doesn't it? How difficult would it be to implement this? As I said before, I'm willing to help for this. cheers, == Olivier On 29/10/2007, Christopher Barker <Chr...@no...> wrote: > > Eric Firing wrote: > > Somewhere along the line, it may make sense to support the metric system > > better in mpl. > > It seems to me that the "right" way to do this is to use some sort of > "array-with_units" class. Then what MPL would except was a "length", and > the user would specify what they want. i.e: > > figure(figsize = units.inches((8.5,11)) > > rather than: > > figure(figsize = (8.5, 11), units=inches) > > Though this does make for more typing. With the later way, a system > default for units could be used more easily. > > I really want a unit class like this for other stuff anyway. > > -- just thinking in email.... > > -Chris > > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chr...@no... > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Sat, Nov 03, 2007 at 05:43:55PM +0100, Olivier Verdier wrote: > This is much worse than I thought. The "inch" unit is used in many places in > matplotlib. In particular in `figure` and `savefig`. Please, please consider > allowing other units. Let me emphasise this once more: in Europe, and, I > believe in most places around the world, one NEVER uses inches. Neither in > engineering nor, i think, in typography. For most people "inch" is basically > an unusual measure of how big screens are. I'm not kidding. Same for dpi, > it's a specific measurement of a resolution but nobody thinks of it as a > number of pixels per inches. > I have nothing against an internal use of inches inside matplotlib but > please consider allowing other units for all kinds of interfaces with the > user! > > The best choice in my opinion would be to have a unit preference in the > .matplotlibrc file. This unit could be, say, `inch` or `cm` (or mm). Then > any length would be expressed using this unit of length. That seems simple > enough, doesn't it? You have to be careful about the use of global flags which change the behaviour of a library --- they make it very difficult to write applications that work on all users machines. Consider an application where you have two graphs on the same page, and you want the axes to be aligned. The only way to do this reliably is to set the margin size. If you write code assuming mm and the users machine uses inches, the results will not be pretty. One solution is to attach units to all your values. With a set of base units that supports multiplication by scalars, this could be something like: figure(figsize=(100*mm,50*mm)) A sensible default such as printer points is needed if no units are specified. The reason you need to carry around the units is that you may want the size to scale with the font. For example, you may want to provide for 6 digits in the tic labels, so the margin should be ten times the width of a single digit (allowing for sign and spaces). Currently margins and legend boxes scale with the size of the plot, which is not ideal. Latex uses these units: mm Millimetres cm Centimetres in Inches pt Points (1in = 72.27pt) pc Picas (1pc = 12pt) em The width of the letter M in the current font ex The height of the letter x in the current font - Paul