matplotlib-users Mailing List for matplotlib

Hi,
I am having trouble with matplotlib 1.0.1 drawing the axis tick labels over
the legend box in the eps output when useTex is set to true. The plot shown
after calling plt.show() looks fine, as does the output in pdf, png, svg
etc. Only the postscript appears to be affected.
The following simple example produces the png and eps files given at the
bottom of this post:
import matplotlib as mpl
import matplotlib.pyplot as plt
from matplotlib import rc
rc('text', usetex=True)
g1 = plt.plot([1,2,3,4],[500,600,700,800])
g2 = plt.plot([1,2,3,4],[700,300,700,200])
g3 = plt.plot([1,2,3,4],[800,600,900,800])
plt.figlegend([g1,g2,g3],['test1','test2','test3'],'upper left')
plt.savefig('image.png')
plt.savefig('image.eps')
plt.show()
http://old.nabble.com/file/p31744864/image.eps image.eps 
http://old.nabble.com/file/p31744864/image.png image.png 
I would very much appreciate some help resolving this issue.
Thanks
-- 
View this message in context: http://old.nabble.com/eps-and-useTex%3A-tick-labels-drawn-over-legend-box-tp31744864p31744864.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

>
>
> Good catch. Ian Thomas fixed the contouring algorithm so that it
> handles masked regions perfectly.
>
> Eric
>
>
> When did that happen? I can make it a "versionadded" note so that users
> of older versions won't be confused.
It was about 15 months ago. I think it is better to just delete any 
reference to the problem.
Eric
>
> Ben Root
>

On Tue, May 31, 2011 at 2:38 PM, Eric Firing <ef...@ha...> wrote:
> On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>>
>>
>>
>> On Tue, May 31, 2011 at 12:58 PM, Eric Firing
>> <ef...@ha... <mailto:ef...@ha...>
>> <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>>
>> On 05/31/2011 05:50 AM, Benjamin Root wrote:
>> >
>> >
>> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>> > <ant...@jp...
>> <mailto:ant...@jp...>
>> <mailto:ant...@jp...
>> <mailto:ant...@jp...>>
>> > <mailto:ant...@jp...
>> <mailto:ant...@jp...>
>> <mailto:ant...@jp...
>> <mailto:ant...@jp...>>>> wrote:
>> >
>> > The following program seems to work with contour/contourf.
>> However
>> > the documentation for the contourf function states
>> >
>> > contour(X,Y,Z)
>> >
>> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>> >
>> > I am finding that contour works if the dimension of X and Y
>> are 1,
>> > but Z must be two-dimensional. The following program seems
>> to
>> bear
>> > this out. Are the arrays x and y below two-dimensional,
>> or is the
>> > documentation misleading? Thanks for your help.
>> >
>> > import numpy as N
>> > import pylab as PLT
>> >
>> > lons = N.linspace(-5.,5.,5) # Is this a one or two
>> dimensional array?
>> > lats = N.linspace(-3.,3.,4)
>> >
>> > z = N.zeros((len(lats), len(lons)))
>> > for i in range(len(lons)):
>> > for j in range(len(lats)):
>> > z[j,i]=i+j
>> >
>> > PLT.clf()
>> > PLT.contourf(lons,lats,z)
>> > PLT.colorbar()
>> > PLT.show()
>> >
>> > -Tony
>> >
>> >
>> > Tony,
>> >
>> > contour and contourf seems to take advantage of numpy's
>> broadcasting
>> > feature, so it is probably more correct to say that X and Y must
>> be at
>> > least broadcastable to the shape of Z. I think there are a
>> number of
>>
>> Not quite; if x and y are 1-D, meshgrid is called to make
>> 2-D versions,
>> which must then match Z. Broadcasting is not used or
>> supported. So, the
>> contour docstring was not updated when this functionality
>> was added,
>> long ago. Consider it an undocumented feature, in need of
>> documentation.
>>
>> Eric
>>
>>
>> Well, (as a bit of a cop-out) in my edit, I didn't say that they
>> were
>> broadcasted, only that they must be broadcastable to the same
>> shape.
>> Would that suffice, or should I re-word that?
>>
>>
>> It would not be correct.
>>
>> x and y must both be 2-D, with the same shape as z; or they must
>> both be 1-D such that len(x) is the number of columns in z and
>> len(y) is the number of rows.
>>
>> Eric
>>
>>
>> Gotcha, I didn't think about the mixed 1-D and 2-D case.
>>
>> In addition, is the note in the contour doc about masked arrays still
>> valid, or can this be removed/updated?
>>
>> "*Z* may be a masked array, but filled contouring may not handle
>> internal masked regions correctly."
>>
>
> Good catch. Ian Thomas fixed the contouring algorithm so that it handles
> masked regions perfectly.
>
> Eric
>
>
When did that happen? I can make it a "versionadded" note so that users of
older versions won't be confused.
Ben Root

On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
>
> On Tue, May 31, 2011 at 12:58 PM, Eric Firing
> <ef...@ha... <mailto:ef...@ha...>
> <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>
> On 05/31/2011 05:50 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> > <ant...@jp...
> <mailto:ant...@jp...>
> <mailto:ant...@jp...
> <mailto:ant...@jp...>>
> > <mailto:ant...@jp...
> <mailto:ant...@jp...>
> <mailto:ant...@jp...
> <mailto:ant...@jp...>>>> wrote:
> >
> > The following program seems to work with contour/contourf.
> However
> > the documentation for the contourf function states
> >
> > contour(X,Y,Z)
> >
> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
> >
> > I am finding that contour works if the dimension of X and Y
> are 1,
> > but Z must be two-dimensional. The following program seems to
> bear
> > this out. Are the arrays x and y below two-dimensional,
> or is the
> > documentation misleading? Thanks for your help.
> >
> > import numpy as N
> > import pylab as PLT
> >
> > lons = N.linspace(-5.,5.,5) # Is this a one or two
> dimensional array?
> > lats = N.linspace(-3.,3.,4)
> >
> > z = N.zeros((len(lats), len(lons)))
> > for i in range(len(lons)):
> > for j in range(len(lats)):
> > z[j,i]=i+j
> >
> > PLT.clf()
> > PLT.contourf(lons,lats,z)
> > PLT.colorbar()
> > PLT.show()
> >
> > -Tony
> >
> >
> > Tony,
> >
> > contour and contourf seems to take advantage of numpy's
> broadcasting
> > feature, so it is probably more correct to say that X and Y must
> be at
> > least broadcastable to the shape of Z. I think there are a
> number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make
> 2-D versions,
> which must then match Z. Broadcasting is not used or
> supported. So, the
> contour docstring was not updated when this functionality
> was added,
> long ago. Consider it an undocumented feature, in need of
> documentation.
>
> Eric
>
>
> Well, (as a bit of a cop-out) in my edit, I didn't say that they
> were
> broadcasted, only that they must be broadcastable to the same shape.
> Would that suffice, or should I re-word that?
>
>
> It would not be correct.
>
> x and y must both be 2-D, with the same shape as z; or they must
> both be 1-D such that len(x) is the number of columns in z and
> len(y) is the number of rows.
>
> Eric
>
>
> Gotcha, I didn't think about the mixed 1-D and 2-D case.
>
> In addition, is the note in the contour doc about masked arrays still
> valid, or can this be removed/updated?
>
> "*Z* may be a masked array, but filled contouring may not handle
> internal masked regions correctly."
Good catch. Ian Thomas fixed the contouring algorithm so that it 
handles masked regions perfectly.
Eric
>
> Ben Root
>

On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...> wrote:
> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>> On 05/31/2011 05:50 AM, Benjamin Root wrote:
>> >
>> >
>> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>> > <ant...@jp...
>> <mailto:ant...@jp...>
>> > <mailto:ant...@jp...
>> <mailto:ant...@jp...>>> wrote:
>> >
>> > The following program seems to work with contour/contourf.
>> However
>> > the documentation for the contourf function states
>> >
>> > contour(X,Y,Z)
>> >
>> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>> >
>> > I am finding that contour works if the dimension of X and Y
>> are 1,
>> > but Z must be two-dimensional. The following program seems to
>> bear
>> > this out. Are the arrays x and y below two-dimensional, or is
>> the
>> > documentation misleading? Thanks for your help.
>> >
>> > import numpy as N
>> > import pylab as PLT
>> >
>> > lons = N.linspace(-5.,5.,5) # Is this a one or two
>> dimensional array?
>> > lats = N.linspace(-3.,3.,4)
>> >
>> > z = N.zeros((len(lats), len(lons)))
>> > for i in range(len(lons)):
>> > for j in range(len(lats)):
>> > z[j,i]=i+j
>> >
>> > PLT.clf()
>> > PLT.contourf(lons,lats,z)
>> > PLT.colorbar()
>> > PLT.show()
>> >
>> > -Tony
>> >
>> >
>> > Tony,
>> >
>> > contour and contourf seems to take advantage of numpy's broadcasting
>> > feature, so it is probably more correct to say that X and Y must
>> be at
>> > least broadcastable to the shape of Z. I think there are a number
>> of
>>
>> Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
>> which must then match Z. Broadcasting is not used or supported. So, the
>> contour docstring was not updated when this functionality was added,
>> long ago. Consider it an undocumented feature, in need of
>> documentation.
>>
>> Eric
>>
>>
>> Well, (as a bit of a cop-out) in my edit, I didn't say that they were
>> broadcasted, only that they must be broadcastable to the same shape.
>> Would that suffice, or should I re-word that?
>>
>
> It would not be correct.
>
> x and y must both be 2-D, with the same shape as z; or they must both be
> 1-D such that len(x) is the number of columns in z and len(y) is the number
> of rows.
>
> Eric
>
>
Gotcha, I didn't think about the mixed 1-D and 2-D case.
In addition, is the note in the contour doc about masked arrays still valid,
or can this be removed/updated?
"*Z* may be a masked array, but filled contouring may not handle internal
masked regions correctly."
Ben Root

On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 05/31/2011 05:50 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> > <ant...@jp...
> <mailto:ant...@jp...>
> > <mailto:ant...@jp...
> <mailto:ant...@jp...>>> wrote:
> >
> > The following program seems to work with contour/contourf.
> However
> > the documentation for the contourf function states
> >
> > contour(X,Y,Z)
> >
> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
> >
> > I am finding that contour works if the dimension of X and Y
> are 1,
> > but Z must be two-dimensional. The following program seems to
> bear
> > this out. Are the arrays x and y below two-dimensional, or is the
> > documentation misleading? Thanks for your help.
> >
> > import numpy as N
> > import pylab as PLT
> >
> > lons = N.linspace(-5.,5.,5) # Is this a one or two
> dimensional array?
> > lats = N.linspace(-3.,3.,4)
> >
> > z = N.zeros((len(lats), len(lons)))
> > for i in range(len(lons)):
> > for j in range(len(lats)):
> > z[j,i]=i+j
> >
> > PLT.clf()
> > PLT.contourf(lons,lats,z)
> > PLT.colorbar()
> > PLT.show()
> >
> > -Tony
> >
> >
> > Tony,
> >
> > contour and contourf seems to take advantage of numpy's broadcasting
> > feature, so it is probably more correct to say that X and Y must
> be at
> > least broadcastable to the shape of Z. I think there are a number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
> which must then match Z. Broadcasting is not used or supported. So, the
> contour docstring was not updated when this functionality was added,
> long ago. Consider it an undocumented feature, in need of
> documentation.
>
> Eric
>
>
> Well, (as a bit of a cop-out) in my edit, I didn't say that they were
> broadcasted, only that they must be broadcastable to the same shape.
> Would that suffice, or should I re-word that?
It would not be correct.
x and y must both be 2-D, with the same shape as z; or they must both be 
1-D such that len(x) is the number of columns in z and len(y) is the 
number of rows.
Eric
>
> Ben Root
>

On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...> wrote:
> On 05/31/2011 05:50 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> > <ant...@jp...
> > <mailto:ant...@jp...>> wrote:
> >
> > The following program seems to work with contour/contourf. However
> > the documentation for the contourf function states
> >
> > contour(X,Y,Z)
> >
> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
> >
> > I am finding that contour works if the dimension of X and Y are 1,
> > but Z must be two-dimensional. The following program seems to bear
> > this out. Are the arrays x and y below two-dimensional, or is the
> > documentation misleading? Thanks for your help.
> >
> > import numpy as N
> > import pylab as PLT
> >
> > lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> > lats = N.linspace(-3.,3.,4)
> >
> > z = N.zeros((len(lats), len(lons)))
> > for i in range(len(lons)):
> > for j in range(len(lats)):
> > z[j,i]=i+j
> >
> > PLT.clf()
> > PLT.contourf(lons,lats,z)
> > PLT.colorbar()
> > PLT.show()
> >
> > -Tony
> >
> >
> > Tony,
> >
> > contour and contourf seems to take advantage of numpy's broadcasting
> > feature, so it is probably more correct to say that X and Y must be at
> > least broadcastable to the shape of Z. I think there are a number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
> which must then match Z. Broadcasting is not used or supported. So, the
> contour docstring was not updated when this functionality was added,
> long ago. Consider it an undocumented feature, in need of documentation.
>
> Eric
>
>
Well, (as a bit of a cop-out) in my edit, I didn't say that they were
broadcasted, only that they must be broadcastable to the same shape. Would
that suffice, or should I re-word that?
Ben Root

On 05/31/2011 05:50 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> <ant...@jp...
> <mailto:ant...@jp...>> wrote:
>
> The following program seems to work with contour/contourf. However
> the documentation for the contourf function states
>
> contour(X,Y,Z)
>
> "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>
> I am finding that contour works if the dimension of X and Y are 1,
> but Z must be two-dimensional. The following program seems to bear
> this out. Are the arrays x and y below two-dimensional, or is the
> documentation misleading? Thanks for your help.
>
> import numpy as N
> import pylab as PLT
>
> lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> lats = N.linspace(-3.,3.,4)
>
> z = N.zeros((len(lats), len(lons)))
> for i in range(len(lons)):
> for j in range(len(lats)):
> z[j,i]=i+j
>
> PLT.clf()
> PLT.contourf(lons,lats,z)
> PLT.colorbar()
> PLT.show()
>
> -Tony
>
>
> Tony,
>
> contour and contourf seems to take advantage of numpy's broadcasting
> feature, so it is probably more correct to say that X and Y must be at
> least broadcastable to the shape of Z. I think there are a number of
Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions, 
which must then match Z. Broadcasting is not used or supported. So, the 
contour docstring was not updated when this functionality was added, 
long ago. Consider it an undocumented feature, in need of documentation.
Eric
> functions where this may or may not be true, and at some point we (the
> developers) should agree on basic input array handling and make it
> consistent across all plotting functions.
>
> So, technically speaking, the docs are "right", but should be clearer in
> this case. I will add it to my doc-fixing commit that I will do today.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 05/30/2011 11:42 PM, Eric O LEBIGOT (EOL) wrote:
>
>
> efiring wrote:
>>
>> Stop saying you want to avoid show(); (...). You probably *need* to use
>> show; with 1.0.1
The above was wrong--see below. If you start with interactive mode on, 
you do not need show at all. In non-interactive mode, you do need show.
>> in interactive mode, it will not block. Your script can close the
>> windows; your user doesn't have to do so manually.
>>
> You are right: your script shows that the latest (1.0.1) show() is great, as
> it is non-blocking in interactive mode (except with the macosx backend).
> (It is the pre-1.0.1 blocking show() that was not a solution.)
>
>
> efiring wrote:
>>
>> It sounds like you are indeed talking about a free-standing script, that
>> is, not involving ipython or other intermediate shell, correct?
>>
> Correct.
>
>
> efiring wrote:
>>
>> Does the attached
>> script illustrate something roughly like what you are trying to do?
>>
> Yes, it does, thanks. Just a detail: since the interactive mode is on, the
> plt.draw()s in the second part are not necessary, are they?
Not a detail: you do need the draw if you are not ending with a pyplot 
function, as opposed to an object method. You could just use the pyplot 
function, plt.plot(), instead of the method, ax.plot(), etc., which 
would call the draw automatically.
Now, you may find that everything works the same if you eliminate the 
first draw in my example; that is because the plt.figure() call has put 
a draw request in to the gui toolkit, and the toolkit is not executing 
it right away. Don't rely on this, however; if you are using the object 
methods, call draw when you want the figure to be refreshed.
>
> So, to summarize, the latest 1.0.1 show() does the actual drawing (not
> draw()), is non-blocking in interactive mode, and can be called multiple
> times. This is both convenient (no need to manually close umpteen windows
> one by one), and efficient (non interactive mode can be used up until show()
> is called). Thus, the practical side of the problem is closed: thanks!
Not quite. Draw() ensures that everything is up to date; show() is not a 
direct substitute.
In my example script, I should have put the call to plt.ion() *before* 
all other pyplot calls. If you do that, then you actually don't need the 
show() at all, because the the initial call to plt.figure() in 
interactive mode displays the figure.
>
> I have been asking these questions because I have been using and teaching
> (Python and) Matplotlib for 3 years, now, to students who use a variety of
> OSes, so I wanted to get things straight.
>
> On the "theoretical" side, draw() is actually rarely used for drawing or
> refreshing simple figures (including common non-animated figures), but is
> more for "some more advanced features such as animations and widgets, as
> well as for internal use.", as Ben was writing, right? And show() is really
> the function that commonly does the actual display or refresh, right? If
> this is correct, I will be done with my questions.
> :-)
>
No, if you use object methods rather than the pyplot interface, then you 
need to use draw(). For example, if you try changing the last draw() in 
my example to a show(), the new line will not be added.
Eric

On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G) <
ant...@jp...> wrote:
> The following program seems to work with contour/contourf. However the
> documentation for the contourf function states
>
> contour(X,Y,Z)
>
> "*X*, *Y*, and *Z* must be arrays with the same dimensions."
>
> I am finding that contour works if the dimension of X and Y are 1, but Z
> must be two-dimensional. The following program seems to bear this out. Are
> the arrays x and y below two-dimensional, or is the documentation
> misleading? Thanks for your help.
>
> import numpy as N
> import pylab as PLT
>
> lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> lats = N.linspace(-3.,3.,4)
>
> z = N.zeros((len(lats), len(lons)))
> for i in range(len(lons)):
> for j in range(len(lats)):
> z[j,i]=i+j
>
> PLT.clf()
> PLT.contourf(lons,lats,z)
> PLT.colorbar()
> PLT.show()
>
> -Tony
>
>
Tony,
contour and contourf seems to take advantage of numpy's broadcasting
feature, so it is probably more correct to say that X and Y must be at least
broadcastable to the shape of Z. I think there are a number of functions
where this may or may not be true, and at some point we (the developers)
should agree on basic input array handling and make it consistent across all
plotting functions.
So, technically speaking, the docs are "right", but should be clearer in
this case. I will add it to my doc-fixing commit that I will do today.
Ben Root

The following program seems to work with contour/contourf. However the documentation for the contourf function states
contour(X,Y,Z)
"X, Y, and Z must be arrays with the same dimensions."
I am finding that contour works if the dimension of X and Y are 1, but Z must be two-dimensional. The following program seems to bear this out. Are the arrays x and y below two-dimensional, or is the documentation misleading? Thanks for your help.
import numpy as N
import pylab as PLT
lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
lats = N.linspace(-3.,3.,4)
z = N.zeros((len(lats), len(lons)))
for i in range(len(lons)):
 for j in range(len(lats)):
 z[j,i]=i+j
PLT.clf()
PLT.contourf(lons,lats,z)
PLT.colorbar()
PLT.show()
-Tony
--
Tony Mannucci
Supervisor, Ionospheric and Atmospheric Remote Sensing Group
 Mail-Stop 138-308, Tel > (818) 354-1699
 Jet Propulsion Laboratory, Fax > (818) 393-5115
 California Institute of Technology, Email > Ton...@jp...<mailto:Ton...@jp...>
 4800 Oak Grove Drive, http://genesis.jpl.nasa.gov
 Pasadena, CA 91109

Hi Matplotlib Users,
First of all, I hope this is the right place to ask my questions, otherwise, apologies for the spam.
I am trying to install python on my mac (10.6.7) and I have some issues when trying to import pylab. 
I installed python 2.7.1 from the EDP package (32-bit), I have numpy 1.5.0 and matplotlib 1.0.0.
I can import both numpy and matplotlib successfully (backend is MacOSX, I also tried TkAgg).
But no matter how I try to import pylab ("import pylab", "from pylab import *", "ipython -pylab", "from matplotlib import pylab") I always have the following message:
> >>> import pylab
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/pylab.py", line 1, in <module>
> from matplotlib.pylab import *
> File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/pylab.py", line 216, in <module>
> from matplotlib import mpl # pulls in most modules
> File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/mpl.py", line 2, in <module>
> from matplotlib import axis
> File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/axis.py", line 10, in <module>
> import matplotlib.font_manager as font_manager
> File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/font_manager.py", line 52, in <module>
> from matplotlib import ft2font
> ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/ft2font.so, 2): Library not loaded: @rpath/libfreetype.6.dylib
> Referenced from: /Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/ft2font.so
> Reason: image not found
Just to be sure, a "which python" returns:
> /Library/Frameworks/Python.framework/Versions/7.0/bin/python
I also checked that I do have the "ft2font.so" file inside /Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/.
To me it seems that the library "libfreetype.6.dylib" cannot be found, but I must confess I have no idea what this @rpath is. Of course, I already tried to google this but couldn't find a proper solution. A "locate libfreetype.6.dylib" returns the following:
> /Applications/TeX/TeXworks.app/Contents/Frameworks/libfreetype.6.dylib
> /Applications/VLC.app/Contents/MacOS/lib/libfreetype.6.dylib
> /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libfreetype.6.dylib
> /Developer/SDKs/MacOSX10.6.sdk/usr/X11/lib/libfreetype.6.dylib
> /Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib
> /usr/X11/lib/libfreetype.6.dylib
Using the otool -L to see the different links of the last two files here's what I have:
> >otool -L /Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib
> /Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib:
> 	@rpath/libfreetype.6.dylib (compatibility version 13.0.0, current version 13.2.0)
> 	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> >otool -L /usr/X11/lib/libfreetype.6.dylib
> /usr/X11/lib/libfreetype.6.dylib:
> 	/usr/X11/lib/libfreetype.6.dylib (compatibility version 13.0.0, current version 13.0.0)
> 	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
> 	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
> 	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.34.0)
And then, I'm completely lost and I have no idea how to proceed. Anyone has an idea how to solve this ?
Thanks a lot,
Johan

efiring wrote:
> 
> Stop saying you want to avoid show(); (...). You probably *need* to use
> show; with 1.0.1 
> in interactive mode, it will not block. Your script can close the 
> windows; your user doesn't have to do so manually.
> 
You are right: your script shows that the latest (1.0.1) show() is great, as
it is non-blocking in interactive mode (except with the macosx backend). 
(It is the pre-1.0.1 blocking show() that was not a solution.)
efiring wrote:
> 
> It sounds like you are indeed talking about a free-standing script, that 
> is, not involving ipython or other intermediate shell, correct?
> 
Correct.
efiring wrote:
> 
> Does the attached 
> script illustrate something roughly like what you are trying to do?
> 
Yes, it does, thanks. Just a detail: since the interactive mode is on, the
plt.draw()s in the second part are not necessary, are they?
So, to summarize, the latest 1.0.1 show() does the actual drawing (not
draw()), is non-blocking in interactive mode, and can be called multiple
times. This is both convenient (no need to manually close umpteen windows
one by one), and efficient (non interactive mode can be used up until show()
is called). Thus, the practical side of the problem is closed: thanks!
I have been asking these questions because I have been using and teaching
(Python and) Matplotlib for 3 years, now, to students who use a variety of
OSes, so I wanted to get things straight.
On the "theoretical" side, draw() is actually rarely used for drawing or
refreshing simple figures (including common non-animated figures), but is
more for "some more advanced features such as animations and widgets, as
well as for internal use.", as Ben was writing, right? And show() is really
the function that commonly does the actual display or refresh, right? If
this is correct, I will be done with my questions.
:-)
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31739359.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

One-line correction to script attached to last post; so use the one 
attached here.

On 05/30/2011 09:59 PM, Eric O LEBIGOT (EOL) wrote:
>
> I really appreciate your continuing this discussion, Ben.
>
> Benjamin Root-2 wrote:
>>
>> On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL)<
>> Eri...@no...> wrote:
>> Question: would displaying a figure (or a group of figures), pausing to
>> let
>> you close them, and then continuing to the next figures more along the
>> lines
>> of what you want? That is certainly possible with matplotlib. Since
>> v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
>> for certain backends to do this correctly).
>>
> Yeah, the new show() is nice. However, I don't want my users to have to
> close the numerous opened figures one by one, even if it is done in 4 times
> 3 clicks (and, again, it would not be convenient to put the graphs in
> subplots). So, what I am really looking for is really: (1) display figures
> without having to use show(); and (2) do this efficiently (without automatic
> drawing through the interactive mode).
>
>
> Benjamin Root-2 wrote:
>>
>> (...) In pyplot, nearly all
>> drawing commands have as the final step a call to a function called
>> "draw_if_interactive()".
>> (...)
>> You could call directly call
>> draw() on each object you want re-drawn, but you don't have to. You can
>> give a single call to a parent object that would call draw() for all of
>> its
>> children objects.
>> (...)
>>
> Thank you for these more theoretical explanations, which are interesting.
>
> However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
> backend), or 1.0.0 Mac OS X (default backend and GTKAgg). The main problem
> is that draw() does unfortunately not draw anything in non-interactive mode
> (this happens when there is no show() in the code)! So, with these two
> recent version, in *non*-interactive mode, it does not appear that "a
> refresh does not occur until you tell it to with a call to draw()", and
> things like this. There is no refresh at all, and pyplot.draw() does
> display anything (this is illustrated by the last program example I posted).
> As far as I can see, theory and practice strongly clash, about the
> "refreshing" effect of the draw() command (in non-interactive mode), as I
> can't see anything being refreshed or displayed by draw. What is your take
> on this?
>
> Thank you for the idea of bypassing pyplot's automatic update in interactive
> mode. How is this done? Doing ax.draw(ax.figure.canvas.renderer) raises a
> RunTime error with the default Mac OS X backend, and an AttributeError with
> the GTKAgg backend. How should the draw() method of Matplotlib objects be
> called?
>
> Now that I'm thinking of it, the crux of the problem might be that
> pyplot.figure() does *not* open any window, in non-interactive mode (until
> show() is called, which I want to avoid). This looks like a bad start if
> draw() is to refresh anything... Could this be the main stumbling block? Can
> a new window be opened in non-interactive mode (without using show())?
Stop saying you want to avoid show(); let's just figure out how to get 
to the desired end result. You probably *need* to use show; with 1.0.1 
in interactive mode, it will not block. Your script can close the 
windows; your user doesn't have to do so manually.
It sounds like you are indeed talking about a free-standing script, that 
is, not involving ipython or other intermediate shell, correct?
Can you come up with a minimal example of what you want it to do, and 
how you want the user to be able to interact with it? Does the attached 
script illustrate something roughly like what you are trying to do?
Eric

I really appreciate your continuing this discussion, Ben.
Benjamin Root-2 wrote:
> 
> On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <
> Eri...@no...> wrote:
> Question: would displaying a figure (or a group of figures), pausing to
> let
> you close them, and then continuing to the next figures more along the
> lines
> of what you want? That is certainly possible with matplotlib. Since
> v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
> for certain backends to do this correctly).
> 
Yeah, the new show() is nice. However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots). So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).
Benjamin Root-2 wrote:
> 
> (...) In pyplot, nearly all
> drawing commands have as the final step a call to a function called
> "draw_if_interactive()".
> (...)
> You could call directly call
> draw() on each object you want re-drawn, but you don't have to. You can
> give a single call to a parent object that would call draw() for all of
> its
> children objects.
> (...)
> 
Thank you for these more theoretical explanations, which are interesting.
However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg). The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)! So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this. There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted). 
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw. What is your take
on this?
Thank you for the idea of bypassing pyplot's automatic update in interactive
mode. How is this done? Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend. How should the draw() method of Matplotlib objects be
called?
Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid). This looks like a bad start if
draw() is to refresh anything... Could this be the main stumbling block? Can
a new window be opened in non-interactive mode (without using show())?
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31738725.html
Sent from the matplotlib - users mailing list archive at Nabble.com.