matplotlib-users Mailing List for matplotlib (Page 13)

Dear all,

I want to print the plotted curves to a printer NOT to a file.
if you know somthing such as "QwtPlotPrintFilter " class in Qwt.

Which module help me?

-- 
View this message in context: http://old.nabble.com/print-to-aprint-device%21-tp29149286p29149286.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi

I have tried the mpl and glade examples and tried different approaches
from the net, but I can only get button_press_event to work with a matplot
canvas. key_press_event does not work using gtkagg for GUI.

Is this due to the gtk builder 2.16? I mean does the main window steal the
key_presses or something?

I had previously tried an example without a gtk gui (don't remember the
example). There a callback was connected and it could get events
containing both mouse click and keypress. I mean if I pressed the mouse
button while keeping doen say 'e' I could get form event.key that 'e' was
pressed when I click the mouse.

I have to use gtk for the rest of the GUI so when I tried to pack the
canvas into gtk I got the problem that callbacks and connections didn't
work. i guess it has to do with that gtk has it's own callback system.

If anybody has some example code, tips or tricks, I would very much
appreciate that. I cannot at the moment provide an example code due to
project deadline, but will do afterwards.

thanks in advance

Preben

> On 07/13/2010 02:05 AM, John Hunter wrote:
>> I also see buggy behavior, but on my ubuntu linux system I see that
>> the whole subplot gets painted black on a mouse press and remains so
>> while the rubber-banding is in effect.  It's not strictly black, but
>> it looks like blackish bit noise.  I also notice if I don't add the
>> combobox to the vbox, I have no problem.  But I don't see that the
>> "plot moves"....
>
> By the plot moves, I mean that with a reasonably sized control on top of
> the plot the lower x axis seems to shoot upward during the zoom. See the
> attached example.

I see the same moving on one of my PCs (64-bit) in Ubuntu 10.04. But the
movement is much larger.

On 07/13/2010 02:05 AM, John Hunter wrote:
> I also see buggy behavior, but on my ubuntu linux system I see that
> the whole subplot gets painted black on a mouse press and remains so
> while the rubber-banding is in effect.  It's not strictly black, but
> it looks like blackish bit noise.  I also notice if I don't add the
> combobox to the vbox, I have no problem.  But I don't see that the
> "plot moves"....

By the plot moves, I mean that with a reasonably sized control on top of 
the plot the lower x axis seems to shoot upward during the zoom. See the 
attached example.


>
> It;s somewhat reminiscent of this pixel noise I once reported working
> on another gtkagg problem.
>
> Interestingly, I'm seeing the same behavior with backend gtk and gtkagg.
>
> All of which is discouraging: we both see bugs but different ones on
> linux,

Actually I think we are seeing the same bug (the blackish noise). I've 
included screen shots both on the original post and this one so you can 
see what happens while the mouse is pressed.

>the appearance of the bug is caused by adding a combobox which
> is not used (on my system), the bug appears on some platforms (linux)
> but not others (win) and it appears for both gtk and gtkagg.
>

I agree with you that it does look like a gtk bug, although it's not 
ComboBox specific, as the example attached to this message uses a Label.

JLS

Hi,

I wanna know how to clip text outside a polygon path.
In the attached a.png file, the polygon with red facecolor and green
edgecolor is a Path. I want to get rid of the text 'aaaaaaaaunicode:
Institut' outside the polygon and keep the part inside the polygon
('aaaaaaa') left.

my code as follows. It can work out a 'right' result as i wanted.
------------------
# -*- coding: utf-8 -*-
import matplotlib.pyplot as plt
import matplotlib.path as mpath
import matplotlib.patches as mpatches

import matplotlib.pyplot as plt 
from matplotlib.transforms import * 


Path=mpath.Path

lines = [ [1,1.5],[1,6],[6,3],[3,1.5],[1,1.5] ]

codes=[Path.LINETO]*len(lines)
codes[0]=Path.MOVETO
codes[-1]=Path.CLOSEPOLY
path=mpath.Path(lines,codes)
patch=mpatches.PathPatch(path,facecolor='red',edgecolor='green',lw=2)#,alpha=1)


fig = plt.figure()
fig.suptitle('bold figure suptitle', fontsize=14, fontweight='bold')
ax = fig.add_subplot(111)
fig.subplots_adjust(top=0.85)
ax.set_title('axes title')
ax.set_xlabel('xlabel')
ax.set_ylabel('ylabel')
ax.text(3, 8, 'boxed italics text in data coords', style='italic',
bbox={'facecolor':'red', 'alpha':0.5, 'pad':10})
ax.text(2, 6, r'an equation: $E=mc^2$', fontsize=15)

t=ax.text(3, 2, unicode('aaaaaaaaunicode: Institut f\374r Festk\366rperphysik', 'latin-1'))
t.set_clip_path(patch)

ax.text(0.95, 0.01, 'colored text in axes coords',
verticalalignment='bottom', horizontalalignment='right',
transform=ax.transAxes,
color='green', fontsize=15)
ax.plot([2], [1], 'o')
ax.annotate('annotate', xy=(2, 1), xytext=(3, 4),
arrowprops=dict(facecolor='black', shrink=0.05))
ax.axis([0, 10, 0, 10])

ax.add_patch(patch)
ax.set_clip_path(patch)


plt.show()

-------------------


Can anybody give me a example?
thanks.

                   david.shu
                   2010.7.13

I was wrong in my last email. I was running another script and has a residual image from when I uploaded. I will test this and and post back.

On Jul 12, 2010, at 6:15 PM, Jeff Whitaker wrote:

> On 7/12/10 5:34 PM, Steve McFarlin wrote:
>> Hello,
>> 
>> I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.
>> 
>> # do this before importing pylab or pyplot
>> import matplotlib
>> matplotlib.use('Agg')
>> import matplotlib.pyplot as plt
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> ax.plot([1,2,3])
>> fig.savefig('test.png')
>> 
>> However, I receive the following results when using basemap
>> 
>> Traceback (most recent call last):
>>  File "testImageGen.py", line 117, in<module>
>>    setCommonBaseMapProperties(m)
>>  File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
>>    bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
>>  File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
>>    self.set_axes_limits(ax=ax)
>>  File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
>>    and not ax.get_autoscalex_on()
>> AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'
>> 
>> 
>> I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?
>> 
>> 
>> - steve
>> 
>> 
> 
> Steve:  What's your matplotlib version?  Does adding
> 
> ax.get_autoscalex_on()
> 
> in your first script cause that to fail as well?
> 
> -Jeff
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

On Mon, Jul 12, 2010 at 8:05 PM, John Hunter <jd...@gm...> wrote:
> All of which is discouraging: we both see bugs but different ones on
> linux, the appearance of the bug is caused by adding a combobox which
> is not used (on my system), the bug appears on some platforms (linux)
> but not others (win) and it appears for both gtk and gtkagg.

The last thing I'll add for now is that my bug, the black pixel noise
(fills the axes window when motion starts in a zoom-to-rect event)
which may be unrelated to your bug, is happening in
backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of
calls:

  # this is used to copy the background that the zoom to rect
"rubberband" will be drawn over
  self._imageBack = axrect, drawable.get_image(*axrect)

  # this is used to restore the background before redrawing the
rectangle for the zoom box
  drawable.draw_image(gc, imageBack, 0, 0, *lastrect)

Since the bug is only exposed when a combo box is added to the
hierarchy, and appears to be platform or gtk specific, I'm suspecting
a gtk bug at this point.  But I don't have anything conclusive or a
minimal example which I could use to post to the gtk list.  The mpl
calls and values (axrect, lastrect, etc) look correct on inspection.
Somehow the call to drawable.get_image is getting a buffer full of
noise if and only if the combobox is added to the vbox.

JDH

On 7/12/10 5:34 PM, Steve McFarlin wrote:
> Hello,
>
> I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.
>
> # do this before importing pylab or pyplot
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
> fig.savefig('test.png')
>
> However, I receive the following results when using basemap
>
> Traceback (most recent call last):
>   File "testImageGen.py", line 117, in<module>
>     setCommonBaseMapProperties(m)
>   File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
>     bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
>   File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
>     self.set_axes_limits(ax=ax)
>   File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
>     and not ax.get_autoscalex_on()
> AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'
>
>
> I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?
>
>
> - steve
>
>    

Steve:  What's your matplotlib version?  Does adding

ax.get_autoscalex_on()

in your first script cause that to fail as well?

-Jeff

Hello Jeff,

Again this was an issue with my lack of understanding. Installing python-matplotlib-data solved the issue. 

Thanks once again.

- Steve (aka. AbstractMapping)

On Jul 12, 2010, at 6:15 PM, Jeff Whitaker wrote:

> On 7/12/10 5:34 PM, Steve McFarlin wrote:
>> Hello,
>> 
>> I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.
>> 
>> # do this before importing pylab or pyplot
>> import matplotlib
>> matplotlib.use('Agg')
>> import matplotlib.pyplot as plt
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> ax.plot([1,2,3])
>> fig.savefig('test.png')
>> 
>> However, I receive the following results when using basemap
>> 
>> Traceback (most recent call last):
>>  File "testImageGen.py", line 117, in<module>
>>    setCommonBaseMapProperties(m)
>>  File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
>>    bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
>>  File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
>>    self.set_axes_limits(ax=ax)
>>  File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
>>    and not ax.get_autoscalex_on()
>> AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'
>> 
>> 
>> I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?
>> 
>> 
>> - steve
>> 
>>   
> 
> Steve:  What's your matplotlib version?  Does adding
> 
> ax.get_autoscalex_on()
> 
> in your first script cause that to fail as well?
> 
> -Jeff
> 
> 
> 

On Mon, Jul 12, 2010 at 6:39 PM, João Luís Silva <js...@fc...> wrote:
>
>
> John Hunter wrote:
>>
>> On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva
>> <jsi...@pu...> wrote:
>>>
>>> Hi,
>>>
>>> I've finally created a small script that demonstrates a bug that I've
>>> been
>>> enduring for a long time. I haven't seen it reported before, so I may be
>>> doing something wrong. The bug is as follows: Under certain conditions,
>>> in
>>> an embedded gtk application, when selecting an area with the "Zoom to
>>> rectangle" button from the toolbar the whole graph will jump upward
>>> temporarily, corrupting the screen and making it hard to select the
>>> proper
>>> area. The attached example is an extreme version of this (the effect
>>> would
>>> be smaller for a reasonably sized combo box).
>>>
>>> Tested on Linux (Debian Squeeze).
>>
>>
>> You have this line:
>>
>>  from widgets import Widgets
>>
>> what is "widgets"  ?
>>
>> JDH
>>
>
> Sorry, I forgot to delete it. It's just a small helper class I use to load
> files from glade. By the way, I just tested the script on Windows (after
> deleting that line) and it doesn't have the bug (Python 2.5 + mpl 1.0.0)

I also see buggy behavior, but on my ubuntu linux system I see that
the whole subplot gets painted black on a mouse press and remains so
while the rubber-banding is in effect.  It's not strictly black, but
it looks like blackish bit noise.  I also notice if I don't add the
combobox to the vbox, I have no problem.  But I don't see that the
"plot moves"....

It;s somewhat reminiscent of this pixel noise I once reported working
on another gtkagg problem.

Interestingly, I'm seeing the same behavior with backend gtk and gtkagg.

All of which is discouraging: we both see bugs but different ones on
linux, the appearance of the bug is caused by adding a combobox which
is not used (on my system), the bug appears on some platforms (linux)
but not others (win) and it appears for both gtk and gtkagg.

JDH

http://old.nabble.com/gtkagg-pixel-buffer-bug-td18051692.html

After a reinstallation of a few libraries the error message changed. It is as if basemap is not linked to matplotlib.

Traceback (most recent call last):
  File "testImageGen.py", line 117, in <module>
    setCommonBaseMapProperties(m)
  File "/home/forecast/sgWaveModel/sgUtil.py", line 38, in setCommonBaseMapProperties
    bmap.drawmapboundary(linewidth=0.0, color=[15./255., 53./255.,73./255.]) 
  File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1325, in drawmapboundary
    for spine in ax.spines.itervalues():
AttributeError: 'AxesSubplot' object has no attribute 'spines'

I am using basemap 1.0 and all the latest libraries for everything required by PIL, matplotlib, pygrib, pyproj etc....


On Jul 12, 2010, at 4:34 PM, Steve McFarlin wrote:

> Hello,
> 
> I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.
> 
> # do this before importing pylab or pyplot
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
> fig.savefig('test.png')
> 
> However, I receive the following results when using basemap
> 
> Traceback (most recent call last):
> File "testImageGen.py", line 117, in <module>
>   setCommonBaseMapProperties(m)
> File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
>   bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
> File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
>   self.set_axes_limits(ax=ax)
> File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
>   and not ax.get_autoscalex_on()
> AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'
> 
> 
> I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?
> 
> 
> - steve
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Hello,

I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.

# do this before importing pylab or pyplot
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])
fig.savefig('test.png')

However, I receive the following results when using basemap

Traceback (most recent call last):
 File "testImageGen.py", line 117, in <module>
   setCommonBaseMapProperties(m)
 File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
   bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
 File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
   self.set_axes_limits(ax=ax)
 File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
   and not ax.get_autoscalex_on()
AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'


I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?


- steve

John Hunter wrote:
> On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote:
>> Hi,
>>
>> I've finally created a small script that demonstrates a bug that I've been
>> enduring for a long time. I haven't seen it reported before, so I may be
>> doing something wrong. The bug is as follows: Under certain conditions, in
>> an embedded gtk application, when selecting an area with the "Zoom to
>> rectangle" button from the toolbar the whole graph will jump upward
>> temporarily, corrupting the screen and making it hard to select the proper
>> area. The attached example is an extreme version of this (the effect would
>> be smaller for a reasonably sized combo box).
>>
>> Tested on Linux (Debian Squeeze).
> 
> 
> You have this line:
> 
>   from widgets import Widgets
> 
> what is "widgets"  ?
> 
> JDH
> 

Sorry, I forgot to delete it. It's just a small helper class I use to 
load files from glade. By the way, I just tested the script on Windows 
(after deleting that line) and it doesn't have the bug (Python 2.5 + mpl 
1.0.0)

JLS

On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote:
> Hi,
>
> I've finally created a small script that demonstrates a bug that I've been
> enduring for a long time. I haven't seen it reported before, so I may be
> doing something wrong. The bug is as follows: Under certain conditions, in
> an embedded gtk application, when selecting an area with the "Zoom to
> rectangle" button from the toolbar the whole graph will jump upward
> temporarily, corrupting the screen and making it hard to select the proper
> area. The attached example is an extreme version of this (the effect would
> be smaller for a reasonably sized combo box).
>
> Tested on Linux (Debian Squeeze).


You have this line:

  from widgets import Widgets

what is "widgets"  ?

JDH

On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne <je...@mi...> wrote:
> Actually, I have been able to do it like this:
>
> mpl.rcParams['patch.linewidth'] = 0.2
>
> Hope that helps, and sorry I didn't reply sooner.

Of course this will affect any other patches in your figure (eg
Rectangles from histogram plots, etc).

I am not opposed to adding some legend.frame rc parameters.  Part of
the purpose of the rc file is to work like a style sheet, so if you
are writing a book or an article with a bunch of figures, and you want
them all the have the same look-and-feel, you can customize the
defaults externally w/o a bunch of boilerplate in your scripts that
can be difficult to maintain.  It seems like the legend frame
properties fit into this category.  In particular, the frame alpha is
one I almost always set to semi-transparent so you can see data behind
the legend, which is boilerplate I might be happy to do away with if I
had an rc param.

I would be amenable to adding:

  legend.frame.facecolor : 'white'
  legend.frame.edgecolor : 'white'
  legend.frame.linewidth : 1.0
  legend.frame.alpha : 1.0

but I'd like to hear from others (Eric?) who are already not happy
with the size of our rc file.  Although this change would increase the
line count, it doesn't increase the complexity much if at all in my
view and is somewhat useful.  It would imply some mild potential
breakage, because currently the legend face and edge colors use the
axes colors (which is why it would be nice if we had
containment/inheritance for our rc params so they could inherit from
parent) so if someone has tweaked their old axes.facecolor, they would
need to add legend.frame.facecolor under this change to remain
compatible.

JDH

Hi,

I've finally created a small script that demonstrates a bug that I've 
been enduring for a long time. I haven't seen it reported before, so I 
may be doing something wrong. The bug is as follows: Under certain 
conditions, in an embedded gtk application, when selecting an area with 
the "Zoom to rectangle" button from the toolbar the whole graph will 
jump upward temporarily, corrupting the screen and making it hard to 
select the proper area. The attached example is an extreme version of 
this (the effect would be smaller for a reasonably sized combo box).

Tested on Linux (Debian Squeeze).

Regards,
João Luís Silva

On Jul 12, 2010, at 5:45 PM, Janne Blomqvist wrote:

>>> a.legend()
>>
>> Change this to
>>
>>  lg = a.legend()
>>  fr = lg.get_frame()
>>  fr.set_lw(0.2)
>
> Thanks, this solved it. A bit annoying that it can't be done with rc
> params, but hey, at least it works.

Hi Janne,

Actually, I have been able to do it like this:

mpl.rcParams['patch.linewidth'] = 0.2

Hope that helps, and sorry I didn't reply sooner.

-Jeff

On 2010-07-12 23:17:19 +0200, John Hunter said:

> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye 
> <kmi...@gm...> wrote:
>> Dear all,
>> 
>> I'm not sure if this is by design or a problem:
>> 
>> In a pylab session, if I repeatedly call imshow with the same image,
>> memory increases each time.
>> This does not happen if i go the 'Artists' way (fig = .., ax =
>> fig.add---, im = ax.imshow)
>> Is there a way to avoid memory consumption like this in the pylab style?
>> Even a clf() does not release the memory.
>> My config is the latest Enthought distribution in 32-bit mode for MacOS.
>> 
> 
> 
> Can you post a complete free-standing script that we can run which
> exposes the problem?  Also please report your version numbers -- we
> could look them up from enthought perhaps but you can help us :-)

Of course, sorry.
But because I don't know how to read out Python's memory consumption 
from within python, these lines should be run successively in Ipython, 
so that one can see, how the 'Real Mem' system indicator grows each 
time.

l = [28.1]
arr = ones((1500,1500,3))
l.append(79.7)
imshow(arr)
l.append(172.0)
imshow(arr)
l.append(249.0))
l.append(249.0)
imshow(arr)
l.append(326.3))
l.append(326.3)
imshow(arr)
l.append(404.4)
imshow(arr)
l.append(482.4)

This was run in an ipython session started with the -pylab flag.
The numbers in the l array are the MBs I read of Mac's Activity Monitor 
for the Python task.
Here is the resulting plot:
http://dl.dropbox.com/u/139035/mem_growth.png

Here's my system info:

Darwin paradigm.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 
18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386

In [25]: print matplotlib.__version__
-------> print(matplotlib.__version__)
0.99.3

Enthought Python Distribution -- http://code.enthought.com

Python 2.6.5 |EPD 6.2-2 (32-bit)| (r265:79063, May 28 2010, 15:13:03)

my matplotlibrc (some adaptations):
http://dl.dropbox.com/u/139035/matplotlibrc


Hope this is all you need?

BR,
Michael


> 
> http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

On Sat, Jul 10, 2010 at 18:42, Jouni K. Seppänen <jk...@ik...> wrote:
> Janne Blomqvist <blo...@gm...> writes:
>
>> The problem I'm having is that as the figure is then pretty small, I
>> can scale font sizes, axis sizes, line widths etc., but what I've been
>> unable to figure out is how to scale dashed or dotted lines, as well
>> as the thickness of the legend border box.
>
> It seems that there are no rc settings for these, but you can adjust
> them as follows:
>
>> a.plot(x, y, '--', label='foo bar')
>
> Change this to
>
>  a.plot(x, y, '--', label='foo bar', dashes=(2,2))
>
> The value of dashes is the number of points of ink followed by the
> number of points of whitespace. It defaults to (6,6) for the '--'
> linestyle (found in the dashd dictionary of backend_bases.py).
>
>> a.legend()
>
> Change this to
>
>  lg = a.legend()
>  fr = lg.get_frame()
>  fr.set_lw(0.2)

Thanks, this solved it. A bit annoying that it can't be done with rc
params, but hey, at least it works.


-- 
Janne Blomqvist

On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye <kmi...@gm...> wrote:
> Dear all,
>
> I'm not sure if this is by design or a problem:
>
> In a pylab session, if I repeatedly call imshow with the same image,
> memory increases each time.
> This does not happen if i go the 'Artists' way (fig = .., ax =
> fig.add---, im = ax.imshow)
> Is there a way to avoid memory consumption like this in the pylab style?
> Even a clf() does not release the memory.
> My config is the latest Enthought distribution in 32-bit mode for MacOS.
>


Can you post a complete free-standing script that we can run which
exposes the problem?  Also please report your version numbers -- we
could look them up from enthought perhaps but you can help us :-)

http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting

Dear all,

I'm not sure if this is by design or a problem:

In a pylab session, if I repeatedly call imshow with the same image, 
memory increases each time.
This does not happen if i go the 'Artists' way (fig = .., ax = 
fig.add---, im = ax.imshow)
Is there a way to avoid memory consumption like this in the pylab style?
Even a clf() does not release the memory.
My config is the latest Enthought distribution in 32-bit mode for MacOS.

BR,
Michael

Hi,

Is there a way to get the current colorbar (or a list of colorbars) for the
current axes and update the mappable property? If an update is not possible,
i would like to replace the current colorbar with a new one.


I've tried something similar to the following:

import pylab as plt
fig = plt.figure()
ax = fig.add_subplot(111)
x = range(10)
y = range(10)
z = range(10)
scatter1 = ax.scatter(x,y,c=z,visible=False)
cbar = fig.colorbar(scatter1)
z = range(10,20)
scatter2 = ax.scatter(x,y,c=range(10,20),visible=True)
cbar.mappable = scatter2
plt.show()

but the colorbar is still on the range 0...9.

Also, is there a way to control the visibility of the colorbar?

Thanks,
Aman

Ah, I misread your original post and thought you were talking about pcolor.
I will take a look at plot_surface and see if there is a possible reason for
your issue.  I have an idea of what is happening, but I have to see the code
when I get back to my office tomorrow.

Ben Root

On Sun, Jul 11, 2010 at 8:43 PM, Jeremy Conlin <jlc...@gm...> wrote:

> On Friday, July 9, 2010, Benjamin Root <ben...@ou...> wrote:
> > Jeremy,
> >
> > I believe that 0.99.1 is fairly old.  I don't know when Axes3D came
> along, but I am sure you can find it in 0.99.3.  It is most definitely in
> 1.0, but you might not need to go that far if your distro does not provide
> it.
>
> Wince my first post, I have upgraded to 1.0 which definitely has
> Axes3D.  The trouble is that the plot_surface function does not deal
> with masked arrays like color does.  That is what I need and I haven't
> found a way around it.
>
> Jeremy
>

Hello,

I am getting a permission error when trying to open a figure or  
plotting using matplotlib.

	TclError: couldn't open "/Library/Frameworks/Python.framework/ 
Versions/2.6/lib/python2.6/site-packages/matplotlib/mpl-data/images/ 
home.ppm": permission denied

Attached is a test log file.



Isaac Salazar
W-13: ADVANCED ENGINEERING ANALYSIS
TA-03, Building 1400, Room 2229
MS A142
if...@la...
phone: 667 9225

On Sun, Jul 11, 2010 at 12:52 PM, Preben Randhol <ra...@pv...> wrote:

>> If you could create a minimal example starting with
>> embedding_in_gtk3.py that replicates your problem, we're more likely
>> to be able to help.

Thanks for posting the example.  This runs fine for me (I can pan,
zoom, zoom to rect, the zoom to rect rubberband is drawn).  Here is my
version info; what do you have for same?

  johnh@udesktop191:tmp> uname -a
  SunOS udesktop191 5.10 Generic_139556-08 i86pc i386 i86pc
j  ohnh@udesktop191:tmp> python -c 'import gtk; print gtk.pygtk_version'
  (2, 6, 0)

Also, if you know the persion of gtk you are running, that might help.

Finally, you say you are running mpl 1.0, but your traceback says

  "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py", line
  606, in idle_draw drawable.draw_image(gc, imageBack, 0, 0, *lastrect)
  TypeError: Gdk.Drawable.draw_image() argument 2 must be gtk.gdk.Image,
  not None


but line 606 in backend_gtk in mpl 1.0.0 is not what this traceback
says.  Are you sure you are picking up the right version?  I suggest
flushing all your matplotlib* files and dirs in site-packages and
doing a clean install, and then running your test script with
--verbose-debug so we can get a better look at what is happening.
Please post the output which is logged to the terminal.

JDH