From: Toon Verstraelen <Toon.Verstraelen@UGent.be>  20060306 11:17:29

Hi, I'm not sure whether my previous mail has really reached the mailing list or not. Excuse me if it is posted twice. Currently I have written a wrapper script that allows me to set all types of margins in inches instead of relative coordinates: width  the width of the figure in inches height  the height of the figure in inches margins  a list of margins [left, right, bottom, top] in inches spacing  a list containing the horizontal and the vertical spacing between the subplots. pylab.gcf().set_figsize_inches(width, height) all_axes_width = (width  margins[0]  margins[1]) axes_width = (all_axes_width  (pylab.gca().numCols  1)*spacings[0])/pylab.gca().numCols all_axes_height = (self.height  margins[2]  margins[3]) axes_height = (all_axes_height  (pylab.gca().numRows  1)*spacings[1])/pylab.gca().numRows pylab.subplots_adjust( left=margins[0]/width, right=1margins[1]/width, bottom=margins[2]/height, top=1margins[3]/height, wspace=spacings[0]/axes_width, hspace=spacings[1]/axes_height ) I wonder if their is a cleaner way of doing this, without a wrapper function? Is it possible to organize multiple axes in a plot in another way than using the pylab.subplot function? I'm currently preparing a publication for which the plots are created with matplotlib, and I would like to share some of my experiences. The (future) ambition of matplotlib is to create plots that are publicationready. For basic plots this is certainly no problem at all, but for complex plots containing multiple axes etc, the pylab.subplot function is too restrictive. As an example, I have attached one of the types of plots I'm working on. I have to use wrapper functions like the one given above, to make sure that the subplots are squares and the horizontal and vertical distances between them are equal. This is luckily not a blocker, but the choice of working with relative coordinates, is not always ideal. A problem I could not solve up to know, is aligning the labels at the left and the bottom of the plot. Don't get me wrong, I know that it is very difficult to implement a plotting interface that is able to deal with all these details. Are their any development plans to go further that the subplot interface? I have some experience with writing GTKapplications. The GTK library contains a series of widgets (tables, hboxes, vboxes, ...) that are purely used for organizing the positions and sizes of the actual widgets of interest (entries, buttons, labels, ...). A similar approach in matplotlib would be a great improvement. The organizational widgets should have properties like margins, spacings, ..., that can be given in different units (relative or absolute). The actual widgets of interest in this analogy are axes, labels (for the title and axislabels), ticks with labels and legends. What do you matplotlibpeople think of such an idea? Is it completely overengineered? Maybe some parts are already partially implemented? I would be happy to work out this idea and start implementing it. It's a rather huge job, as I am not yet familiar with the complete matplotlib code. Some discussion in advance, also with nondevelopers, is therefore more than welcome. Shoot! regards, Toon 
From: John Hunter <jdhunter@ac...>  20060306 14:14:20

>>>>> "Toon" == Toon Verstraelen <Toon.Verstraelen@...> writes: Toon> Currently I have written a wrapper script that allows me to Toon> set all types of margins in inches instead of relative Toon> coordinates: Toon> I wonder if their is a cleaner way of doing this, without a Toon> wrapper function? Is it possible to organize multiple axes Toon> in a plot in another way than using the pylab.subplot Toon> function? Yes, you want to use the pylab axes function http://matplotlib.sourceforge.net/matplotlib.pylab.html#axes which allows you to place an axes anywhere. Still uses relative coords, but your arithmetic will be *much easier* than it was for subplots. Eg where leftrel is the relative left border and leftin is the left border in inches, you can compute letfrel (which is what axes wants) with leftrel = leftin / figwidth Toon> I'm currently preparing a publication for which the plots Toon> are created with matplotlib, and I would like to share some Toon> of my experiences. The (future) ambition of matplotlib is to Toon> create plots that are publicationready. For basic plots I would argue that this is the current ambition, as I do believe people are submitting matplotlib plots for publication :) I know I have. But you are right, there is certainly work to do, because there is no end to the tinkering people have to do to comply with journal guidelines. And to satisfy their own need to tinker and avoid real work :) Toon> this is certainly no problem at all, but for complex plots Toon> containing multiple axes etc, the pylab.subplot function is Toon> too restrictive. Right, it's just a special case helper function. Here is a screenshot using axes http://matplotlib.sourceforge.net/screenshots.html#axes_demo Toon> As an example, I have attached one of the types of plots I'm Toon> working on. I have to use wrapper functions like the one Toon> given above, to make sure that the subplots are squares and Toon> the horizontal and vertical distances between them are Toon> equal. This is luckily not a blocker, but the choice of Toon> working with relative coordinates, is not always ideal. A I agree. It would be nice to be able to pass in units of your choice, inches, points, cm, relative, pixel, data for all locations. You can do this relatively easy for some datatypes (eg lines, text, etc) by using custom transforms, but not everywhere (eg axes positions are always relative). Toon> problem I could not solve up to know, is aligning the labels Toon> at the left and the bottom of the plot. Don't get me wrong, Toon> I know that it is very difficult to implement a plotting Toon> interface that is able to deal with all these details. Toon> Are their any development plans to go further that the Toon> subplot interface? I have some experience with writing Toon> GTKapplications. The GTK library contains a series of Toon> widgets (tables, hboxes, vboxes, ...) that are purely used Toon> for organizing the positions and sizes of the actual widgets We've talked about this. layout engines like this are pretty hard to do well. As you've noticed, matplotlib doesn't try to be smart, but does try and give you handles to tweak things so that you can ultimately get them where you want them. Toon> of interest (entries, buttons, labels, ...). A similar Toon> approach in matplotlib would be a great improvement. The Toon> organizational widgets should have properties like margins, Toon> spacings, ..., that can be given in different units Toon> (relative or absolute). The actual widgets of interest in Toon> this analogy are axes, labels (for the title and Toon> axislabels), ticks with labels and legends. Toon> What do you matplotlibpeople think of such an idea? Is it Toon> completely overengineered? Maybe some parts are already Toon> partially implemented? I would be happy to work out this Toon> idea and start implementing it. It's a rather huge job, as I Toon> am not yet familiar with the complete matplotlib code. Some Toon> discussion in advance, also with nondevelopers, is Toon> therefore more than welcome. Shoot! You are welcome to work on this. I think it would be a nice addition. You might want to start by looking at the Axis code for example to see how the xlabel and ylabel position are chosen to not overlap the tick labels, as an example of how to work with the matplotlib bounding boxes. This kind of stuff will be essential for your layout algorithms. Cheers, JDH 
From: Toon Verstraelen <Toon.Verstraelen@UGent.be>  20060307 07:13:06
Attachments:
Toon.Verstraelen.vcf

John Hunter wrote: >>>>>>"Toon" == Toon Verstraelen <Toon.Verstraelen@...> writes: > Toon> I wonder if their is a cleaner way of doing this, without a > Toon> wrapper function? Is it possible to organize multiple axes > Toon> in a plot in another way than using the pylab.subplot > Toon> function? > > Yes, you want to use the pylab axes function > > http://matplotlib.sourceforge.net/matplotlib.pylab.html#axes > > which allows you to place an axes anywhere. Still uses relative > coords, but your arithmetic will be *much easier* than it was for > subplots. Eg where leftrel is the relative left border and leftin is > the left border in inches, you can compute letfrel (which is what axes > wants) with > > leftrel = leftin / figwidth Thanks! This makes live a lot easier. > Toon> As an example, I have attached one of the types of plots I'm > Toon> working on. I have to use wrapper functions like the one > Toon> given above, to make sure that the subplots are squares and > Toon> the horizontal and vertical distances between them are > Toon> equal. This is luckily not a blocker, but the choice of > Toon> working with relative coordinates, is not always ideal. A > > I agree. It would be nice to be able to pass in units of your choice, > inches, points, cm, relative, pixel, data for all locations. You can > do this relatively easy for some datatypes (eg lines, text, etc) by > using custom transforms, but not everywhere (eg axes positions are > always relative). Ok, I'll take a look at it. Is it for example also possible to use the transforms to draw a vertical arrow 0.2 inches under a datapoint, that is 0.3 inches long? I mean, can transforms be used to mix different units? > Toon> of interest (entries, buttons, labels, ...). A similar > Toon> approach in matplotlib would be a great improvement. The > Toon> organizational widgets should have properties like margins, > Toon> spacings, ..., that can be given in different units > Toon> (relative or absolute). The actual widgets of interest in > Toon> this analogy are axes, labels (for the title and > Toon> axislabels), ticks with labels and legends. > > Toon> What do you matplotlibpeople think of such an idea? Is it > Toon> completely overengineered? Maybe some parts are already > Toon> partially implemented? I would be happy to work out this > Toon> idea and start implementing it. It's a rather huge job, as I > Toon> am not yet familiar with the complete matplotlib code. Some > Toon> discussion in advance, also with nondevelopers, is > Toon> therefore more than welcome. Shoot! > > You are welcome to work on this. I think it would be a nice > addition. You might want to start by looking at the Axis code for > example to see how the xlabel and ylabel position are chosen to not > overlap the tick labels, as an example of how to work with the > matplotlib bounding boxes. This kind of stuff will be essential for > your layout algorithms. Indeed, this won't be simple. Does someone have some information pointers about layout engines? Without a little background, chances are small that I will ever come up with something that makes sense. We'll see. regards, Toon 