matplotlib-users Mailing List for matplotlib (Page 21)

On Sat, May 2, 2009 at 5:00 PM, Gideon Simpson <si...@ma...>wrote:
> I have two time series, {u_j} and {v_j}, with vastly different scales,
> but all sampled at the same times, {t_j}. Is there an easy way to
> plot the two on the same figure, with different vertical axes on the
> left and the right?
>
Take a look at twinx -- function doc and example links included below:
 http://matplotlib.sourceforge.net/examples/api/two_scales.html
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.twinx
JDH

I have two time series, {u_j} and {v_j}, with vastly different scales, 
but all sampled at the same times, {t_j}. Is there an easy way to 
plot the two on the same figure, with different vertical axes on the 
left and the right?
-gideon

Thomas Robitaille wrote:
> Not sure if this will help, but maybe you can do something like this?
> 
> ---
> #!/usr/bin/env python
> 
> from pylab import *
> from scipy import *
To run this as a standalone script, without ipython -pylab, you need to 
include:
ion()
> 
> img = standard_normal((40,40))
> image = imshow(img,interpolation='nearest',animated=True,label="blah")
> 
> for k in range(1,10000):
> img = standard_normal((40,40))
> image.set_data(img)
> show()
show() should never be called more than once for a given figure; what 
you want here is draw().
Eric
> ---
> 
> Note, interpolation='nearest' can be faster than interpolation=None if 
> your default interpolation is set to bicubic (which it probably is)
> 
> Does this speed things up?
> 
> Thomas
> 
> On May 1, 2009, at 3:31 PM, Joey Wilson wrote:
> 
>> I am creating a script that generates images and displays them to 
>> the screen in real time. I created the following simple script:
>>
>> __________________________
>>
>> #!/usr/bin/env python
>>
>> from pylab import *
>> from scipy import *
>>
>> for k in range(1,10000):
>> img = standard_normal((40,40))
>> imshow(img,interpolation=None,animated=True,label="blah")
>> clf()
>> show()
>>
>> __________________________
>>
>> Now, this script plots the image too slowly. I am forced to use 
>> the clf() function so that it doesn't slow down at each iteration of 
>> the for loop. Is there a way that I can plot this simple image 
>> faster? What's the best way to get imshow() to plot quickly? 
>> Thanks for your help.
>>
>> -Joey
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code 
>> vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf_______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Not sure if this will help, but maybe you can do something like this?
---
#!/usr/bin/env python
from pylab import *
from scipy import *
img = standard_normal((40,40))
image = imshow(img,interpolation='nearest',animated=True,label="blah")
for k in range(1,10000):
 img = standard_normal((40,40))
 image.set_data(img)
 show()
---
Note, interpolation='nearest' can be faster than interpolation=None if 
your default interpolation is set to bicubic (which it probably is)
Does this speed things up?
Thomas
On May 1, 2009, at 3:31 PM, Joey Wilson wrote:
> I am creating a script that generates images and displays them to 
> the screen in real time. I created the following simple script:
>
> __________________________
>
> #!/usr/bin/env python
>
> from pylab import *
> from scipy import *
>
> for k in range(1,10000):
> img = standard_normal((40,40))
> imshow(img,interpolation=None,animated=True,label="blah")
> clf()
> show()
>
> __________________________
>
> Now, this script plots the image too slowly. I am forced to use 
> the clf() function so that it doesn't slow down at each iteration of 
> the for loop. Is there a way that I can plot this simple image 
> faster? What's the best way to get imshow() to plot quickly? 
> Thanks for your help.
>
> -Joey
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code 
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

There was a typo in the script, the callbacks should be
ax.name = "first axis" 
ax.callbacks.connect('xlim_changed',check_callback) 
ax.callbacks.connect('ylim_changed',check_callback) 
ax2 = ax.twin() 
ax2.name = "second axis" 
ax2.callbacks.connect('xlim_changed',check_callback) 
ax2.callbacks.connect('ylim_changed',check_callback) 
but the problem remains: check_callback is never called for ax2.
Tom
-- 
View this message in context: http://www.nabble.com/Enforcing-common-view-limits-tp23334325p23348806.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I've realized that using the ParasiteAxes from the mpl_toolkits should do
exactly what I'm asking. However, I am having a problem with callbacks when
the x and y limits change (try resizing the window). The following script
shows that the callback for the second set of axes is not carried out. Is
this a bug, or a limitation? Or something I'm doing wrong?
Thanks!
Thomas
---
import matplotlib.pyplot as mpl
import numpy as np
import mpl_toolkits.axes_grid.parasite_axes as mpl_toolkit
def check_callback(ax):
 print "callback for ",ax.name
 
array = np.random.random((100,100))
fig = mpl.figure()
ax = mpl_toolkit.SubplotHost(fig,1,1,1,adjustable='datalim')
ax.name = "first axis"
ax.callbacks.connect('xlim_changed',check_callback)
ax.callbacks.connect('xlim_changed',check_callback)
ax2 = ax.twin()
ax2.name = "second axis"
ax2.callbacks.connect('ylim_changed',check_callback)
ax2.callbacks.connect('ylim_changed',check_callback)
fig.add_axes(ax)
ax.imshow(array,interpolation='nearest')
fig.canvas.draw()
---
-- 
View this message in context: http://www.nabble.com/Enforcing-common-view-limits-tp23334325p23348018.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi all!
I'd like to embed a mpl graph into a GTK application (and for that
embedding_in_gtk*.py examples are fine) but I would also like to
dynamically update the graph with time.
Consider like if I want to plot some dynamic system information, like
cpu usage, memory occupation, or so. Than I want to gather those info
at 1 sec interval, and dynamically update the graph adding the new
values.
How can I do it? I'm stuck with the "update data as they come" part
(please note I need for GTK embedded mpl code).
Thanks in advance,
Sandro
PS: if there's someone that knows how to gather cpu percentage usage
on a linux sys, please tell me :) It seems not that easy to find it
out from google ;)
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Thanks!
Thomas
On 1 May 2009, at 15:04, Eric Firing wrote:
> Christopher Barker wrote:
>> Eric Firing wrote:
>>> Split the command up:
>>> p = Circle(...)
>>> ax.add_patch(p, ...)
>>>
>>> (add_* could be modified to return the reference; maybe this would 
>>> be
>>> worthwhile.)
>>
>> +1
>>
>>
>>
>
> Done in r7077.
>
> Eric
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code 
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

The patch seems to work - the MacOSX backend now displays the same 
font size as the other backends.
Thanks!
Thomas
On 1 May 2009, at 14:06, Michael Droettboom wrote:
> Michiel de Hoon provided a patch for this which I just applied to 
> the trunk.
>
> As I don't have a Mac, I can't test it -- any feedback is welcome.
>
> Mike
>
> Jae-Joon Lee wrote:
>> Thomas,
>> As John suggested before, please check if the size differences go 
>> away
>> if you use the same dpi, actually dpi=72.
>>
>> After some quick look, it seems that the osx backend does not scale
>> the font size correctly respecting the dpi.
>> At line 124 of bacend_macosx.py,
>>
>> size = prop.get_size_in_points()
>> weight = prop.get_weight()
>> style = prop.get_style()
>> gc.draw_text(x, y, unicode(s), family, size, weight, 
>> style, angle)
>>
>> My quick guess is that replacing
>>
>> size => size*self.dpi/72.
>>
>> in the last call may solve the problem. Since I don't use the osx
>> backend, I wonder if others can test this.
>>
>> -JJ
>>
>>
>> On Thu, Apr 30, 2009 at 9:32 AM, Michael Droettboom 
>> <md...@st...> wrote:
>>
>>> I forwarded this message to Michiel de Hoon, the author of the Mac 
>>> OS-X
>>> backend, in case he has any thoughts.
>>>
>>> Mike
>>>
>>> Thomas Robitaille wrote:
>>>
>>>> Hi Jae-Jong and John,
>>>>
>>>> Thanks for your replies! While experimenting with this to send
>>>> screenshots, I realized that my default backend was set to 
>>>> MacOSX, not
>>>> WXAgg. The WXAgg output to the screen actually agrees with the 
>>>> PNG output in
>>>> terms of font sizes. But the font sizes differ between the MacOSX 
>>>> and WXAgg
>>>> backends. Attached are screenshots using the MacOSX and WXAgg 
>>>> backends. You
>>>> can see the font size is different. Is this a bug?
>>>>
>>>> Thanks,
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> On 29 Apr 2009, at 00:24, Jae-Joon Lee wrote:
>>>>
>>>>
>>>>> On Tue, Apr 28, 2009 at 11:09 PM, John Hunter 
>>>>> <jd...@gm...> wrote:
>>>>>
>>>>>> If you want the relative fontsizes in the figure window and 
>>>>>> saved figure
>>>>>> to
>>>>>> agree, pass the same "dpi" to the figure command and savefig 
>>>>>> command.
>>>>>>
>>>>> John,
>>>>> I thought the font size (which is specified in points) is 
>>>>> independent
>>>>> of dpi, i.e., font size in "pixel" actually scales with the dpi. I
>>>>> think it should be filed as a bug if the relative font size 
>>>>> depends on
>>>>> the dpi.
>>>>>
>>>>> Anyhow, I just did a quick test and the (relative) font size 
>>>>> does not
>>>>> seem to vary with dpi.
>>>>>
>>>>> Thomas,
>>>>> What version of mpl are you using?
>>>>> With the mpl from the svn trunk, I don't see any significant 
>>>>> change as
>>>>> you described.
>>>>> The WxAgg figure and the png output are actually drawn by an 
>>>>> identical
>>>>> backend, so there should be no significant difference. There can 
>>>>> be
>>>>> some subtle difference due to different dpi, but I don't see a
>>>>> difference as large as 30%. Can you post a some sample images? 
>>>>> i.e., a
>>>>> screenshot of WxAgg figure and the png output.
>>>>>
>>>>> I can see that the text in pdf output occupies a bit larger area 
>>>>> than
>>>>> png (when usetex=False), but, to me, this seems to be due to 
>>>>> different
>>>>> amount of kernings (it seems that no kerning is applied for pdf 
>>>>> text)
>>>>> instead of different font size.
>>>>>
>>>>> So, can you first check if the difference goes away when you use 
>>>>> same
>>>>> dpi as John suggested? And if that is the case, can you try the 
>>>>> latest
>>>>> svn and check if the relative font size still depends on the dpi?
>>>>>
>>>>> Regards,
>>>>>
>>>>> -JJ
>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Register Now & Save for Velocity, the Web Performance & Operations
>>>> Conference from O'Reilly Media. Velocity features a full day of 
>>>> expert-led,
>>>> hands-on workshops and two days of sessions from industry leaders 
>>>> in
>>>> dedicated Performance & Operations tracks. Use code vel09scf and 
>>>> Save an
>>>> extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>

Gideon Simpson wrote:
> Is there a way to construct a figure to have a certain width, setting 
> the height proportionally, so that this will be the actual size if I 
> then save it as a PNG?
I don't understand quite what you are after, but this may help:
http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Is there a way to construct a figure to have a certain width, setting 
the height proportionally, so that this will be the actual size if I 
then save it as a PNG?
-gideon

I am creating a script that generates images and displays them to the screen
in real time. I created the following simple script:
__________________________
#!/usr/bin/env python
from pylab import *
from scipy import *
for k in range(1,10000):
 img = standard_normal((40,40))
 imshow(img,interpolation=None,animated=True,label="blah")
 clf()
 show()
__________________________
Now, this script plots the image too slowly. I am forced to use the clf()
function so that it doesn't slow down at each iteration of the for loop. Is
there a way that I can plot this simple image faster? What's the best way
to get imshow() to plot quickly? Thanks for your help.
-Joey

Christopher Barker wrote:
> Eric Firing wrote:
>> Split the command up:
>> p = Circle(...)
>> ax.add_patch(p, ...)
>>
>> (add_* could be modified to return the reference; maybe this would be 
>> worthwhile.)
> 
> +1
> 
> 
> 
Done in r7077.
Eric

Michiel de Hoon provided a patch for this which I just applied to the trunk.
As I don't have a Mac, I can't test it -- any feedback is welcome.
Mike
Jae-Joon Lee wrote:
> Thomas,
> As John suggested before, please check if the size differences go away
> if you use the same dpi, actually dpi=72.
>
> After some quick look, it seems that the osx backend does not scale
> the font size correctly respecting the dpi.
> At line 124 of bacend_macosx.py,
>
> size = prop.get_size_in_points()
> weight = prop.get_weight()
> style = prop.get_style()
> gc.draw_text(x, y, unicode(s), family, size, weight, style, angle)
>
> My quick guess is that replacing
>
> size => size*self.dpi/72.
>
> in the last call may solve the problem. Since I don't use the osx
> backend, I wonder if others can test this.
>
> -JJ
>
>
> On Thu, Apr 30, 2009 at 9:32 AM, Michael Droettboom <md...@st...> wrote:
> 
>> I forwarded this message to Michiel de Hoon, the author of the Mac OS-X
>> backend, in case he has any thoughts.
>>
>> Mike
>>
>> Thomas Robitaille wrote:
>> 
>>> Hi Jae-Jong and John,
>>>
>>> Thanks for your replies! While experimenting with this to send
>>> screenshots, I realized that my default backend was set to MacOSX, not
>>> WXAgg. The WXAgg output to the screen actually agrees with the PNG output in
>>> terms of font sizes. But the font sizes differ between the MacOSX and WXAgg
>>> backends. Attached are screenshots using the MacOSX and WXAgg backends. You
>>> can see the font size is different. Is this a bug?
>>>
>>> Thanks,
>>>
>>> Thomas
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> On 29 Apr 2009, at 00:24, Jae-Joon Lee wrote:
>>>
>>> 
>>>> On Tue, Apr 28, 2009 at 11:09 PM, John Hunter <jd...@gm...> wrote:
>>>> 
>>>>> If you want the relative fontsizes in the figure window and saved figure
>>>>> to
>>>>> agree, pass the same "dpi" to the figure command and savefig command.
>>>>> 
>>>> John,
>>>> I thought the font size (which is specified in points) is independent
>>>> of dpi, i.e., font size in "pixel" actually scales with the dpi. I
>>>> think it should be filed as a bug if the relative font size depends on
>>>> the dpi.
>>>>
>>>> Anyhow, I just did a quick test and the (relative) font size does not
>>>> seem to vary with dpi.
>>>>
>>>> Thomas,
>>>> What version of mpl are you using?
>>>> With the mpl from the svn trunk, I don't see any significant change as
>>>> you described.
>>>> The WxAgg figure and the png output are actually drawn by an identical
>>>> backend, so there should be no significant difference. There can be
>>>> some subtle difference due to different dpi, but I don't see a
>>>> difference as large as 30%. Can you post a some sample images? i.e., a
>>>> screenshot of WxAgg figure and the png output.
>>>>
>>>> I can see that the text in pdf output occupies a bit larger area than
>>>> png (when usetex=False), but, to me, this seems to be due to different
>>>> amount of kernings (it seems that no kerning is applied for pdf text)
>>>> instead of different font size.
>>>>
>>>> So, can you first check if the difference goes away when you use same
>>>> dpi as John suggested? And if that is the case, can you try the latest
>>>> svn and check if the relative font size still depends on the dpi?
>>>>
>>>> Regards,
>>>>
>>>> -JJ
>>>> 
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of expert-led,
>>> hands-on workshops and two days of sessions from industry leaders in
>>> dedicated Performance & Operations tracks. Use code vel09scf and Save an
>>> extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 

Peter Pippan wrote:
> Hi,
> 
> I was wondering about the eps output produced by imshow().
> 
> This program
> ----------------------------------------------
> from pylab import *
> Z = rand(10,10)
> imshow(Z,interpolation='nearest',cmap=cm.bone)
> savefig('bone.eps')
> imshow(Z,interpolation='nearest',cmap=cm.gray)
> savefig('gray.eps')
> ----------------------------------------------
> produces files with sizes of
> 11M and 172K for bone.eps and gray.eps
> respectively.
With svn, I get nearly the same size for both, and intermediate between 
your two:
-rw------- 1 efiring efiring 1413040 2009年05月01日 07:19 bone.eps
-rw------- 1 efiring efiring 1407313 2009年05月01日 07:19 gray.eps
> 
> Does anybody know why the difference is that large?
> I would expect a factor of 3 for RGB or 4 if an alpha channel is
> included, but not a factor of about 60.
Yes, it's bizarre. I have no idea what was going on. Fortunately, it 
no longer is.
Eric
> 
> Best regards,
> Peter
> 
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> 200ドル on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I am using the 0.98.5
That works for me too but its gets messed up if I modify theta in order
to rotate the graph
Theta = pi/2 - theta
will cause the circles to appear
If I modify r, then it works ok
 
-----Original Message-----
From: Eric Firing [mailto:ef...@ha...] 
Sent: Friday, May 01, 2009 2:14 AM
To: Ng, Enrico
Subject: Re: [Matplotlib-users] Polar plotting clockwise and rotated
With mpl from svn (and using ipython -pylab), the following works:
rr = rand(36)
r = np.hstack((rr, [rr[0]]))
theta = linspace(0, 2*pi, 37)
polar(theta, r)
Eric

Hello,
I want to create two sets of axes for a figure that would be 
equivalent to
ax = fig.add_subplot(111)
ax2 = 
ax 
.figure 
.add_axes(ax.get_position(True),frameon=False,sharex=ax,sharey=ax)
except that I want to be able to specify different tick locators and 
formatters for ax and ax2. If I remove sharex and sharey, then there 
is no guarantee that both axes have the same view limits. I want to 
enforce common view limits while retaining the independence that would 
allow me to specify different locators/formatters.
I would welcome any advice on how to do this,
Thanks!
Thomas

Can you provide a stand along script that reproduces the problem?
Mike
Gideon Simpson wrote:
> When I try to plot some data, I get:
>
> Floating point exception
>
> How can I track down what's wrong?
>
> -gideon
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

When I try to plot some data, I get:
Floating point exception
How can I track down what's wrong?
-gideon

Michael Droettboom-3 wrote:
> 
> Can you be more specific about why that doesn't work?
> 
Trying to save a plot as, for example, 'image.emf' makes an error message
pop up. This error dialog has the title 'Error saving file', but does not
have any error message in its body.
I hope that is what you mean?
Michael Droettboom-3 wrote:
> 
> What GUI backend are you using? That sounds like a bug in how the file
> selection dialog is being used.
> 
I'm using the Qt4 backend in my application, though the code examples I gave
are created and executed without any GUI backend.
To see this for yourself you could run this example code:
> from pylab import *
> 
> x = [0,1,2,3]
> y = [4,3,2,1]
> 
> figure()
> plot(x,y)
> show()
> 
I'm using the most current version (0.98.5.2) of Matplotlib, just to be
clear about that.
Cheers,
Gert-Jan
-- 
View this message in context: http://www.nabble.com/Manually-enable-export-as-EMF-tp23293186p23333043.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

To emulate the current behavior (which doesn't try to interpolate 
between points) you can pass "resolution=1" to the polar command. But I 
agree with Eric -- it sounds like updating my resolve this issue.
Mike
Eric Firing wrote:
> Ng, Enrico wrote:
> 
>> The rotation and resetting of the labels isn't a big issue.
>> The issues is when I reverse the direction. Matplotlib seems to only
>> want to plot in an anti-clockwise direction. I can transform the data
>> to be backwards so that it looks ok, however when it tries to connect
>> the start and end points, it goes back around and draws a circle instead
>> of just connecting the two points using a straight line. 
>> 
>
> What version of mpl are you using? This sounds like behavior that is 
> not current.
>
> Eric
>
> 
>> On Tuesday 21 April 2009 08:36:35 Michler, Matthias wrote:
>> Hi Enrico,
>>
>> I'm afraid that this functionality is missing in matplotlib, but I'm not
>> an
>> expert so there is still hope that this can be easily achieved.
>>
>> A work around, that comes to my mind is resetting the label values using
>> an
>> idea from another mail on this list
>> ( thetagrids( range(0,360,45), ('E', 'NE', 'N','NW', 'W', 'SW', 'S',
>> 'SE') ) )
>>
>> label_values = [item % 360 for item in range(90, -260, -45)]
>> thetagrids( range(0,360,45), label_values)
>>
>> and using some well defined (linear) transformation for plotting -
>> translating
>> your data to the actual tick positions and corresponding labels.
>>
>> best regards Matthias
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations 
>> Conference from O'Reilly Media. Velocity features a full day of 
>> expert-led, hands-on workshops and two days of sessions from industry 
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Gert-Jan wrote:
> Hello again,
>
> Thanks for the reply! I did some more testing, but I couldn't get it to work
> yet. However, during the testing, I got the idea that I was wrong about what
> backends do; it appears they are only used for creating plots, not for
> saving them. For example:
>
>
>
> 
>> #!/usr/bin/env python
>>
>> import matplotlib
>> matplotlib.use('module://backend_emf')
>> from pylab import *
>>
>> x = [0,1,2,3]
>> y = [4,3,2,1]
>>
>> figure()
>> plot(x,y)
>> savefig('C:\\test.emf')
>>
>> 
>
> This still results in a NotImplemented error. Trying to save as another file
> type (savefig(C':\\test.pdf') for example) won't work anymore, either.
> Trying to save as PDF, for example, gives this error message:
>
>
>
> 
>> ValueError: Format "pdf" is not supported.
>> Supported formats: emf.
>>
>> 
>
> Basically, what I'd like to have is that, when the user views the plot and
> presses the save button, the user can select 'Enhanced Metafile (*.emf)'
> from the file type list and save as EMF.
> 
Can you be more specific about why that doesn't work?
> Well, thanks for the help so far. I hope there is a solution for this.
> Otherwise I think I'll revert to an older version.
>
> PS. It appears as though the Matplotlib creators have forgotten to remove
> EMF from the file type list, as it's still there.
> 
Yes -- that was an oversight.
> Also, there appears to be a bug when saving files, as the selection from the
> file type list is ignored and the file is saved as PNG instead, unless you
> manually add another extension in the name.
> 
What GUI backend are you using? That sounds like a bug in how the file 
selection dialog is being used.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello again,
Thanks for the reply! I did some more testing, but I couldn't get it to work
yet. However, during the testing, I got the idea that I was wrong about what
backends do; it appears they are only used for creating plots, not for
saving them. For example:
> #!/usr/bin/env python
> 
> import matplotlib
> matplotlib.use('module://backend_emf')
> from pylab import *
> 
> x = [0,1,2,3]
> y = [4,3,2,1]
> 
> figure()
> plot(x,y)
> savefig('C:\\test.emf')
> 
This still results in a NotImplemented error. Trying to save as another file
type (savefig(C':\\test.pdf') for example) won't work anymore, either.
Trying to save as PDF, for example, gives this error message:
> ValueError: Format "pdf" is not supported.
> Supported formats: emf.
> 
Basically, what I'd like to have is that, when the user views the plot and
presses the save button, the user can select 'Enhanced Metafile (*.emf)'
from the file type list and save as EMF.
Well, thanks for the help so far. I hope there is a solution for this.
Otherwise I think I'll revert to an older version.
PS. It appears as though the Matplotlib creators have forgotten to remove
EMF from the file type list, as it's still there.
Also, there appears to be a bug when saving files, as the selection from the
file type list is ignored and the file is saved as PNG instead, unless you
manually add another extension in the name.
-- 
View this message in context: http://www.nabble.com/Manually-enable-export-as-EMF-tp23293186p23330477.html
Sent from the matplotlib - users mailing list archive at Nabble.com.