matplotlib-users Mailing List for matplotlib

Are there any plans for incorporating this (what used to be mplot3d) 
into the new matplotlib version?
Lisa Tauxe
Scripps Institution of Oceanography
La Jolla, CA 92093-0220
tel: (858) 534-6084
fax: (858) 534-0784
http://magician.ucsd.edu/~ltauxe/
lt...@uc...
NOTE: Fedex or other courier deliveries address:
300C Ritter Hall
8635 Discovery Way
La Jolla, CA 92037

Hi Jae-Joon,
JL> I just had a quick look at this problem. And I'm posting a quick
JL> solution in case Christoper haven't dig it yet.
My figure looks great with these changes. Thank you very much!
-- 
Christopher Brown, Ph.D.
Department of Speech and Hearing Science
Arizona State University

Hello,
I just had a quick look at this problem. And I'm posting a quick
solution in case Christoper haven't dig it yet.
Index: lib/matplotlib/legend.py
===================================================================
--- lib/matplotlib/legend.py (revision 6138)
+++ lib/matplotlib/legend.py (working copy)
@@ -532,7 +532,11 @@
 # Set the data for the legend patch
 bbox = self._get_handle_text_bbox(renderer)
- bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+ #bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+ bbox = bbox.transformed(self.get_transform())
+ bbox = bbox.padded(self.pad*self.fontsize)
+ bbox = bbox.inverse_transformed(self.get_transform())
+
 l, b, w, h = bbox.bounds
 self.legendPatch.set_bounds(l, b, w, h)
The problem is already well explained by Eric. And my solution is to
interpret the legend.pad as a fraction of the textsize (pad=0.3 seems
to work fine in my eyes). Note that this breaks the backward
compatibility. I personally think the original behavior may have
produced unsatisfactory results in most of the cases and keeping it as
a default may not be a good idea. While I hope others come out with an
elegant solution, I prefer to break the API in this case.
Regards,
-JJ
On Tue, Sep 30, 2008 at 3:38 PM, Eric Firing <ef...@ha...> wrote:
> Christopher Brown wrote:
>> Sorry, meant to send to the list...
>>
>> Hi Eric,
>>
>> EF> > the vertical padding is too large in the first
>> EF> > legend, and too small in the second.
>> EF>
>> EF> This looks to me like a design flaw: the pad is "fractional"
>> EF> (fraction of legend box size), when logically it should be in
>> EF> something like units of legend text height, or possibly in points.
>> EF> This might be easy enough to change, although for backwards
>> EF> compatibility we would need to use a new kwarg.
>>
>> Could you point me to the function where this change needs to occur? I'd
>> like to hack at it, because I have deadline for a figure. I'm searching
>> around in legend.py, is that where I should be looking?
>
> Yes, that is the place. In principle it should be easy to fix, and
> maybe it is...or maybe it isn't. It will certainly have to do with
> transforms, and using the right one the right way in the right place.
>
>>
>> Also, why would a new kwarg be necessary? If the change simply means
>> that the vertical padding is computed correctly, how would that break
>> backward compatibility?
>>
>
> Because the workaround is to fiddle with the pad value for each
> individual case to make the plot look right, so scripts with that
> workaround would fail if suddenly the pad kwarg were to be interpreted
> in sane units.
>
> The new kwarg could be "pad_units", as a modifier for the pad kwarg. Or
> something like a "padpoints" kwarg could be introduced as an overlapping
> replacement. Or we could just break the API and hope it doesn't cause
> too much trouble. I am not sure what the right approach is in this
> case. I'm also not sure whether this is the only place where a "pad"
> value is still in poorly-chosen units. There was another such case that
> we fixed quite a long time ago.
>
> Eric
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I sent the below - with referenced attachments - about 24 hours ago and have yet to see it posted - was it blocked due to the attachments?
DG
--- On Mon, 9/29/08, David Goldsmith <d_l...@ya...> wrote:
> From: David Goldsmith <d_l...@ya...>
> Subject: canvas.print_figure printing a variable amount of my figure
> To: mat...@li...
> Date: Monday, September 29, 2008, 5:59 PM
> I feel like I must be missing something: below is some
> "minimal sample" code which reproduces a
> "problem" I'm seeing in a more complicated
> situation:
> 
> import matplotlib as MPL
> from matplotlib.backends.backend_agg import FigureCanvasAgg
> as FigureCanvas
> from matplotlib.figure import Figure
> 
> for DPI in range(100,201,25):
> fig = Figure(figsize=(12,9), 
> dpi=DPI, 
> frameon=False)
> canvas = FigureCanvas(fig)
> 
> nx, ny = (N.uint16(12*DPI), N.uint16(9*DPI))
> temp = N.indices((ny, nx), N.uint8)
> result = N.zeros_like(temp[0])
> result[:ny/2,:] = temp[0,:ny/2,:] + temp[1,:ny/2,:]
> result[ny/2:,:] = temp[0,ny/2:,:] - temp[1,ny/2:,:]
> fig.figimage(result/N.float(N.max(result)))
> 
> canvas.print_figure("test"+str(DPI)+"dpi.png")
> 
> Attached are the results on my computer (see usage details
> below). Granted, I'm increasing the resolution each
> iteration, but I'm always placing the "cut" in
> the figure half way through - why does the cut keep creeping
> up 'til it disappears?
> 
> Usage details: matplotlib version=? (I forget how to get
> that), numpy version = 1.0.4, Python version = 2.5.2, OS =
> Windows XPProSP3, 504 MB RAM w/ "Physical Address
> Extension" (whatever that means).
> 
> DG
> 
> PS: If the figures don't come through and for some
> reason my code doesn't work on your platform or
> doesn't reproduce the problem, email me and I'll
> email you the figures directly.
 

Christopher Brown wrote:
> Sorry, meant to send to the list...
> 
> Hi Eric,
> 
> EF> > the vertical padding is too large in the first
> EF> > legend, and too small in the second.
> EF>
> EF> This looks to me like a design flaw: the pad is "fractional"
> EF> (fraction of legend box size), when logically it should be in
> EF> something like units of legend text height, or possibly in points.
> EF> This might be easy enough to change, although for backwards
> EF> compatibility we would need to use a new kwarg.
> 
> Could you point me to the function where this change needs to occur? I'd
> like to hack at it, because I have deadline for a figure. I'm searching
> around in legend.py, is that where I should be looking?
Yes, that is the place. In principle it should be easy to fix, and 
maybe it is...or maybe it isn't. It will certainly have to do with 
transforms, and using the right one the right way in the right place.
> 
> Also, why would a new kwarg be necessary? If the change simply means
> that the vertical padding is computed correctly, how would that break
> backward compatibility?
> 
Because the workaround is to fiddle with the pad value for each 
individual case to make the plot look right, so scripts with that 
workaround would fail if suddenly the pad kwarg were to be interpreted 
in sane units.
The new kwarg could be "pad_units", as a modifier for the pad kwarg. Or 
something like a "padpoints" kwarg could be introduced as an overlapping 
replacement. Or we could just break the API and hope it doesn't cause 
too much trouble. I am not sure what the right approach is in this 
case. I'm also not sure whether this is the only place where a "pad" 
value is still in poorly-chosen units. There was another such case that 
we fixed quite a long time ago.
Eric

Thomas Guettler wrote:
> Hi,
> 
> this snippet works if there are more (or less) elements in the menMeans 
> tuple. If
> there are three, it does not work since the bar command thinks the three
> element tuple is a tuple of rgb values. But it is a (r, g, b) tuple.
> 
> I think it is a bug. Should I create a ticket?
Yes it is a bug. I don't think a ticket will be needed. A quick look 
indicates that it will be easy to fix, so I will try to remember to do 
it later today. If I haven't done it within 24 hours, send me a reminder.
> 
> I use 0.98.3
> 
> I helped myself by using rgb2hex. But somehow this is not a good solution.
> Maybe colorConverter.to_rgb should return a subclass of tuple called 
> 'ColorTuple'.
> This way it would be easier to distinguish between a tuple of rgb values 
> and a rgb color tuple.
I don't think this will be necessary, and it would not really solve the 
problem in general. I think we already have a solution, but it is not 
being used in the bar() method.
> 
> {{{
> #!/usr/bin/env python
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib
> 
> cmap=matplotlib.cm.jet
> menMeans = (20, 35, 30) # Does work if there are more or less then three 
> elements in the tuple
> N=len(menMeans)
> ind = np.arange(N) # the x locations for the groups
> width = 0.35 # the width of the bars
> plt.subplot(111)
> color=matplotlib.colors.colorConverter.to_rgb(cmap(0.5))
The call to to_rgb here seems completely unnecessary; cmap returns rgba, 
and the color kwarg should accept that. All the to_rgb() is doing is 
chopping off the alpha value.
Eric
> rects1 = plt.bar(ind, menMeans, width, color=color)
> plt.show()
> }}}
> 
> {{{
> Traceback (most recent call last):
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 333, in expose_event
> self._render_figure(self._pixmap, w, h)
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
> FigureCanvasAgg.draw(self)
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 261, in draw
> self.figure.draw(self.renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 
> 759, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 
> 1523, in draw
> a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/patches.py", line 
> 275, in draw
> rgbFace = colors.colorConverter.to_rgb(self._facecolor)
> File "/usr/lib64/python2.5/site-packages/matplotlib/colors.py", line 
> 280, in to_rgb
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "0,490196078431"
> }}}
> 

Folks,
I sent this msg last Friday but it never appeared in the digest...
I am trying to install, in a private 'space', 0.98.3 on a linux 
x86-64 scientific cluster on which I am not the admin. tcl/tk is 
indeed installed, and I know where they are. matplotlib cannot find 
them. When running 'python setup.py build', tclConfig.sh and 
tkConfig.sh are on the path.
It seems tcl/tk detection is a persistent issue, from searching the 
web. My head hurts right now on this, so I hope there's some kind of 
an answer.
Some output:
> python setup.py build
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.3
 python: 2.5.2 (r252:60911, Sep 25 2008, 16:58:03) [GCC
 4.1.2 20071124 (Red Hat 4.1.2-38)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.1
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.10
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 * Guessing the library and include directories for
 * Tcl and Tk because the tclConfig.sh and
 * tkConfig.sh could not be found and/or parsed.
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Qt: no
 Qt4: no
 Cairo: no

On Tue, Sep 30, 2008 at 6:00 AM, Antonio Gonzalez <ja...@ca...> wrote:
> Hello,
>
> Running the latest mpl (svn 6134), 'fill_between.py' from the examples
> directory fails:
>
> File "fill_between.py", line 2, in <module>
> import matplotlib.numerical_methods as numerical_methods
> ImportError: No module named numerical_methods
Thanks Antonio,
This is now fixed in svn 6134.
JDH

Hello,
Running the latest mpl (svn 6134), 'fill_between.py' from the examples 
directory fails:
File "fill_between.py", line 2, in <module>
 import matplotlib.numerical_methods as numerical_methods
ImportError: No module named numerical_methods
Regards,
Antonio

Hi,
this snippet works if there are more (or less) elements in the menMeans 
tuple. If
there are three, it does not work since the bar command thinks the three
element tuple is a tuple of rgb values. But it is a (r, g, b) tuple.
I think it is a bug. Should I create a ticket?
I use 0.98.3
I helped myself by using rgb2hex. But somehow this is not a good solution.
Maybe colorConverter.to_rgb should return a subclass of tuple called 
'ColorTuple'.
This way it would be easier to distinguish between a tuple of rgb values 
and a rgb color tuple.
{{{
#!/usr/bin/env python
import numpy as np
import matplotlib.pyplot as plt
import matplotlib
cmap=matplotlib.cm.jet
menMeans = (20, 35, 30) # Does work if there are more or less then three 
elements in the tuple
N=len(menMeans)
ind = np.arange(N) # the x locations for the groups
width = 0.35 # the width of the bars
plt.subplot(111)
color=matplotlib.colors.colorConverter.to_rgb(cmap(0.5))
rects1 = plt.bar(ind, menMeans, width, color=color)
plt.show()
}}}
{{{
Traceback (most recent call last):
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 333, in expose_event
 self._render_figure(self._pixmap, w, h)
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 261, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 
759, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 
1523, in draw
 a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/patches.py", line 
275, in draw
 rgbFace = colors.colorConverter.to_rgb(self._facecolor)
 File "/usr/lib64/python2.5/site-packages/matplotlib/colors.py", line 
280, in to_rgb
 raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
ValueError: to_rgb: Invalid rgb arg "0,490196078431"
}}}
-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

Friedrich Hagedorn wrote:
> Yes as *.png. I think it's convinient to understand your problem in a
> few seconds.
> 
The bottom two subplots of the attached.
Peter

I feel like I must be missing something: below is some "minimal sample" code which reproduces a "problem" I'm seeing in a more complicated situation:
import matplotlib as MPL
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
for DPI in range(100,201,25):
 fig = Figure(figsize=(12,9), 
 dpi=DPI, 
 frameon=False)
 canvas = FigureCanvas(fig)
 nx, ny = (N.uint16(12*DPI), N.uint16(9*DPI))
 temp = N.indices((ny, nx), N.uint8)
 result = N.zeros_like(temp[0])
 result[:ny/2,:] = temp[0,:ny/2,:] + temp[1,:ny/2,:]
 result[ny/2:,:] = temp[0,ny/2:,:] - temp[1,ny/2:,:]
 fig.figimage(result/N.float(N.max(result)))
 canvas.print_figure("test"+str(DPI)+"dpi.png")
Attached are the results on my computer (see usage details below). Granted, I'm increasing the resolution each iteration, but I'm always placing the "cut" in the figure half way through - why does the cut keep creeping up 'til it disappears?
Usage details: matplotlib version=? (I forget how to get that), numpy version = 1.0.4, Python version = 2.5.2, OS = Windows XPProSP3, 504 MB RAM w/ "Physical Address Extension" (whatever that means).
DG
PS: If the figures don't come through and for some reason my code doesn't work on your platform or doesn't reproduce the problem, email me and I'll email you the figures directly.
 

Tim Michelsen wrote:
> Hello users and developers of matplot,
> I would like to ask what kind of interpoaltion method is used by
> pylab.countourf()?
> 
> I suppose that it uses linear interpolation to derive the areas between 
> the contour lines.
> 
> Is that true?
> 
> Kind regards,
> Timmie
Timmie,
I am not sure exactly what you are asking. General contouring routines, 
such as the one in mpl, work by subdividing the domain into a set of 
contiguous polygons, calculating the points at which contours cross 
boundaries, and then connecting these points, usually with straight 
lines. Routines differ in the methods used to subdivide the domain and 
in the methods used to connect the points, since this can be ambiguous. 
 The cntr.c code in mpl subdivides the domain into the rectangles given 
by the quadrilateral grid on which the data are provided. In contrast, 
some other routines divide each such rectangle into 4 triangles by 
interpolating a point in the middle.
If you want to contour data that are not on a regular grid, or that are 
on a regular but coarse grid, or that are too noisy to be contoured 
nicely (assuming the noise has a small scale relative to the scale of 
the signal), then you need to use a gridding routine of your choice 
before contouring. It is the job of the gridding routine to do any 
necessary interpolation and/or smoothing.
Eric

Hello users and developers of matplot,
I would like to ask what kind of interpoaltion method is used by
pylab.countourf()?
I suppose that it uses linear interpolation to derive the areas between 
the contour lines.
Is that true?
Kind regards,
Timmie

Hi everybody,
Below you will find a small script that plots the graph of a simple function. 
This code is aimed to be embedded in a GUI application.
I set the subplot dimension with the b.set_position([]) command. The floats 
that are given to set_position() are percents relative to the Figure 
dimensions:
[ left corner x, left corner y, width, height ]
So, here I have put [0.1, 0.1, 0.8, 0.8 ] to have a small space between the 
subplot and the Figure border.
But when I resize the figure with the mouse, the space between the subplot and 
the Figure border is growing or decreasing, due to the relative definition of 
the dimensions.
I would like to be able to define subplot size and position in an absolute 
way. For example, I would like to have a space between the left border of the 
figure and the left border of the subplot being constant equal to 10px.
Is this possible?
Thanks a lot
Julien
####################
from pylab import *
import Tkinter as Tk
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
root = Tk.Tk()
t = arange(0.01, 5.0, 0.01)
s1 = sin(2*pi*t)
f = Figure( figsize = (8,7) )
veryplot = FigureCanvasTkAgg( f
 , master = root )
veryplot.get_tk_widget().pack( side = Tk.LEFT
 , expand = Tk.YES
 , fill = Tk.BOTH )
b = f.add_subplot( 211 )
b.plot( t, s1 )
# [ left corner x, left corner y, width, height ]
b.set_position( [ 0.1, 0.1, 0.8, 0.8 ] )
show()
root.mainloop()
####################

Steffen Wischmann <ste...@un...>
writes:
> I searched the forum and the net but I cannot figure out how I can 
> change the line colors for a boxplot (i.e., making all lines black such 
> as medians, whiskers, boxlines, black).
Change them after plotting, using the returned dictionary:
In [1]: data = random((10,10))
In [2]: r = boxplot(data)
In [3]: r.keys()
Out[3]: ['medians', 'fliers', 'whiskers', 'boxes', 'caps']
In [4]: setp(r['medians'], color='black')
Out[4]: [None, None, None, None, None, None, None, None, None, None]
This allows you to set the various drawing parameters of the different
parts separately, e.g.:
In [5]: setp(r['whiskers'], color='black', lw=2)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Dear All,
Does anyone know of a citation that I can use for Numpy?
Thanks! and all the best,
--Buz

Hi,
I searched the forum and the net but I cannot figure out how I can 
change the line colors for a boxplot (i.e., making all lines black such 
as medians, whiskers, boxlines, black).
the only thing I accomplished is changing the color of all outliers, 
e.g., via:
boxplot(X, sym='r+')
Even setting the general line color like
rc('lines', color='k')
doesn't change anything.
Thanks for any help,
Steffen

Hi,
As far as I know, the destination coordinate of trans* is a display
(canvas) coordinate, not the normalized figure coordinate. It has a
dimension of f.get_figwidth()*f.get_dpi(),
f.get_figheight()*f.get_dpi().
For example, transFigure transforms the normalized figure coordinate
to the display coordinate.
See if something like below works for you.
 ax = gca()
 f = gcf()
 x1, y1, x2, y2 = 0.2, 0.3, 0.4, 0.5
 trans = ax.transData + f.transFigure.inverted()
 ax_x1, ax_y1 = trans.transform_point([x1, y1])
 ax_x2, ax_y2 = trans.transform_point([x2, y2])
 ax_dx, ax_dy = ax_x2 - ax_x1, ax_y2 - ax_y1
 a = axes([ax_x1, ax_y1,ax_dx, ax_dy])
IHTH,
-JJ
On Mon, Sep 29, 2008 at 8:10 AM, Yves Revaz <yve...@ep...> wrote:
> Dear List,
>
> I would like to define a new second plot inside a first plot using the
> axes command.
> But I need the position and size do be defined not by the relative
> figure coordinates
> but by data coordinates.
>
> I have found the following trick :
>
> ax = gca()
> f = gcf()
> x,y = ax.transData.transform([x,y])/f.transFigure.transform([1,1])
> a = axes([x,y,dy,dy])
>
> However, if the position is now ok, the size (dx,dy) is still on
> relative figure coordiate.
> Ok, I could think a bit more and find how its possible to transform it,
> but I would
> like to ask the list if there is an easier way to do that.
>
> By the way, why do I have to divide by f.transFigure.transform([1,1]) ?
> I expected that ax.transData.transform did return already normalized
> values.
>
>
> Thanks in advance.
>
> yves
>
>
>
> --
> (o o)
> --------------------------------------------oOO--(_)--OOo-------
> Yves Revaz
> Laboratory of Astrophysics EPFL
> Observatoire de Sauverny Tel : ++ 41 22 379 24 28
> 51. Ch. des Maillettes Fax : ++ 41 22 379 22 05
> 1290 Sauverny e-mail : Yve...@ep...
> SWITZERLAND Web : http://www.lunix.ch/revaz/
> ----------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi people,
I'm new to unix, python and matplotlib. I've had trouble installing matplotlib. The machine I'm on is running solaris. I tried installing it on my friend's ubuntu box and it worked basically immediately. After some effort I managed to get it to compile and install on solaris.
In python as root when I type "from pylab import *" I get this error:
=========================
ImportError: ld.so.1: python: fatal: relocation error: file /opt/csw/lib/python/site-packages/matplotlib/_path.so: symbol __1c2N6FI_pv_: referenced symbol not found
=========================
As my normal account I get this:
=========================
Traceback (most recent call last):
 File "test.py", line 1, in <module>
 from pylab import *
 File "/opt/csw/lib/python/site-packages/pylab.py", line 1, in <module>
 from matplotlib.pylab import *
 File "/opt/csw/lib/python/site-packages/matplotlib/__init__.py", line 677, in <module>
 rcParams = rc_params()
 File "/opt/csw/lib/python/site-packages/matplotlib/__init__.py", line 598, in rc_params
 fname = matplotlib_fname()
 File "/opt/csw/lib/python/site-packages/matplotlib/__init__.py", line 548, in matplotlib_fname
 fname = os.path.join(get_configdir(), 'matplotlibrc')
 File "/opt/csw/lib/python/site-packages/matplotlib/__init__.py", line 242, in wrapper
 ret = func(*args, **kwargs)
 File "/opt/csw/lib/python/site-packages/matplotlib/__init__.py", line 435, in _get_configdir
 raise RuntimeError("'%s' is not a writable dir; you must set %s/.matplotlib to be a writable dir. You can also set environment variable MPLCONFIGDIR to any writable directory where you want matplotlib data stored "% (h, h))
RuntimeError: '/local/host/home/mctran' is not a writable dir; you must set /local/host/home/mctran/.matplotlib to be a writable dir. You can also set environment variable MPLCONFIGDIR to any writable directory where you want matplotlib data stored
=========================
when I tried to set MPLCONFIGDIR to a directory, I got the earlier error. I tried recompiling and reinstalling to no avail.
I searched on the mailing list for anything like this, but there were no hits. Any ideas how I can fix this?

Dear List,
I would like to define a new second plot inside a first plot using the 
axes command.
But I need the position and size do be defined not by the relative 
figure coordinates
but by data coordinates.
I have found the following trick :
ax = gca()
f = gcf() 
x,y = ax.transData.transform([x,y])/f.transFigure.transform([1,1])
a = axes([x,y,dy,dy])
However, if the position is now ok, the size (dx,dy) is still on 
relative figure coordiate.
Ok, I could think a bit more and find how its possible to transform it, 
but I would
like to ask the list if there is an easier way to do that.
By the way, why do I have to divide by f.transFigure.transform([1,1]) ?
I expected that ax.transData.transform did return already normalized
values.
Thanks in advance.
yves
-- 
 (o o)
--------------------------------------------oOO--(_)--OOo-------
 Yves Revaz
 Laboratory of Astrophysics EPFL
 Observatoire de Sauverny Tel : ++ 41 22 379 24 28
 51. Ch. des Maillettes Fax : ++ 41 22 379 22 05
 1290 Sauverny e-mail : Yve...@ep...
 SWITZERLAND Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

> Thanks, but this wasn't quite what I had in mind. the exportfig m - 
> file trims the size of the white bounding box on the figure, in 
> addition to saving the image. Is there an easy way to do that with 
> matplotlib?
If you produce pdf, pdfcrop is neat.
Best, Martin
-- 
Martin Lüthi an...@tn...

Thanks, but this wasn't quite what I had in mind. the exportfig m - 
file trims the size of the white bounding box on the figure, in 
addition to saving the image. Is there an easy way to do that with 
matplotlib?
-gideon
On Sep 27, 2008, at 5:11 AM, Marius 't Hart wrote:
> Yes:
> savefig
>
> On Fri, 2008年09月26日 at 18:49 -0400, Gideon Simpson wrote:
>> Is there anything akin to this MATLAB script:
>>
>> http://www.mathworks.com/company/newsletters/digest/june00/export/
>>
>> available for mpl? or some simple set of commands that will
>> accomplish the same task?
>> -gideon
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win 
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in 
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Darren Dale wrote:
> On Friday 26 September 2008 18:49:25 Gideon Simpson wrote:
>> Is there anything akin to this MATLAB script:
>>
>> http://www.mathworks.com/company/newsletters/digest/june00/export/
>>
>> available for mpl? or some simple set of commands that will
>> accomplish the same task?
> 
> matplotlib produces publication quality output, and I think you can reproduce 
> all the features of this script by simply modifying your rc parameters. Your 
> on-screen results should look like your eps output, most importantly you need 
> to set your figure.dpi according to your display size. Aside from that, have a 
> look at the default matplotlibrc file for the many options you can customize.
Good answer, but there may be one exception. The Matlab function 
description indicates that it can produce eps files with the cmyk color 
space, which is indeed something that publishers tend to want, and 
something that we don't do. Whether Matlab does it well, and whether 
with some reasonable modification to the mpl ps backend we could do at 
least as well, I don't know.
Eric
> 
> Darren

Momme Butenschÿfffff6n wrote:
> When using the cyl projection with the bluemarble image and a map area 
> is not the global map centered on lon,lat 0,0 I don't get the blue 
> marbel image to adapt to the actual map. Any suggestions?
Momme: Thanks for the report - this is now fixed in SVN, along with your 
other problem with the robinson projection. If you can't update from 
svn, I can make a tarball for you.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328