Currently I have written a wrapper script that allows me to
> set all types of margins in inches instead of relative
> coordinates:
> 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?
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
> 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 publication-ready. 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
> this is certainly no problem at all, but for complex plots
> containing multiple axes etc, the pylab.subplot function is
> 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
> 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
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).
> 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
> GTK-applications. 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
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.
> 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 matplotlib-people think of such an idea? Is it
> completely over-engineered? 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 non-developers, is
> 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