matplotlib-users Mailing List for matplotlib

Hello,
I'm new in matplotlib, but I have became a fat!
First of all, I have to apologize for my bad English, I hope you can
understand what I mean.
Making some programs I have found the same problem:
> -What I want? I want to plot two sets of changing data using the same
> windows.
> -The problem? My code is:
> -----------------------
> x,y = evol.plot_init()
> pylab.ion()
> pylab.subplot(211)
> line,=pylab.plot(x[0],x[1])
> pylab.draw()
> pylab.ylabel('Posiciones')
> for k in pylab.arange(Nt):
> x, y = evol.plot_step()
> line.set_ydata(x[1])
> pylab.draw()
>
>
> pylab.subplot(212)
> line,=pylab.plot(y[0],y[1])
> pylab.draw()
> pylab.ylabel('Momentos')
>
> for k in pylab.arange(Nt):
> x, y = evol.plot_step()
> line.set_ydata(y[1])
> pylab.draw()
> ---------------------------------------------------------------------
> And if you run this, one draw and anim is done first, you have to wait
> it to stop, and then you can see the other want.
> The thing is that I want that the two anim figures runs at the same time.
>
> Any idea?
>

On Wednesday 28 February 2007 02:59:08 pm Suresh Pillai wrote:
> Ooop, sorry I corrupted the pylab.xticks() line in the second part when
> editing. Should read:
>
> pylab.subplot(211)
> pylab.plot(historicalScore05, label='Score 2005')
> pylab.plot(historialNum05, label='Num 2006')
> pylab.setp(pylab.gca(), xticklabels=[])
> pylab.ylabel('Score 2')
> pylab.title('Historical Statistics')
> pylab.legend(loc='upper left')
>
> pylab.subplot(212)
> pylab.plot(historicalScore06, label='Score 06')
> pylab.plot(historicalNum06, label='Num 06')
> pylab.xticks(pylab.arange(numDatapoints),xLabels)
> #xlabels = pylab.axes().get_xticklabels()
That line right there, you are creating a new set of axes, and getting its 
xticklabels, rather than getting the xticklabels of the existing axes. Try:
xlabels = pylab.gca().get_xticklabels()
> #pylab.setp(xlabels, 'rotation', 90)
> pylab.xlabel('Player')
> pylab.ylabel('Score 1')
> pylab.legend(loc='upper left')
Darren

import pylab
data1=[1,2,3,4,5,6,7]
data2=[8,9,10,11,12,13,14]
dates=['01','02','03','04','05','06','07']
pylab.subplot(211)
pylab.plot(data1, label='Score 2005')
pylab.plot(data2, label='Num 2006')
pylab.setp(pylab.gca(), xticklabels=[])
pylab.ylabel('Score 2')
pylab.title('Historical Statistics')
pylab.legend(loc='upper left')
pylab.subplot(212)
pylab.plot(data1, label='Score 06')
pylab.plot(data2, label='Num 06')
pylab.xticks(pylab.arange(7),dates)
#xlabels = pylab.axes().get_xticklabels()
#pylab.setp(xlabels, 'rotation', 90)
pylab.xlabel('Player')
pylab.ylabel('Score 1')
pylab.legend(loc='upper left')
pylab.show()
So, if you run with the two lines commented out, everything is fine. If 
you uncomment the lines, then you get a broken figure.
Thanks,
Suresh
On 2007年2月28日, Darren Dale wrote:
> Would you post an example that we can actually run?
>

Ooop, sorry I corrupted the pylab.xticks() line in the second part when 
editing. Should read:
pylab.subplot(211)
pylab.plot(historicalScore05, label='Score 2005')
pylab.plot(historialNum05, label='Num 2006')
pylab.setp(pylab.gca(), xticklabels=[])
pylab.ylabel('Score 2')
pylab.title('Historical Statistics')
pylab.legend(loc='upper left')
pylab.subplot(212)
pylab.plot(historicalScore06, label='Score 06')
pylab.plot(historicalNum06, label='Num 06')
pylab.xticks(pylab.arange(numDatapoints),xLabels)
#xlabels = pylab.axes().get_xticklabels()
#pylab.setp(xlabels, 'rotation', 90)
pylab.xlabel('Player')
pylab.ylabel('Score 1')
pylab.legend(loc='upper left')
Using:
numpy-1.0
matplotlib-0.87.7
The result is a small empty plot (plot frame only: no labels, ticks, data, 
legend) within an empty plot of subplot 212 (no data, no legend, but yes 
for ticks and axis titles).
Thanks,
Suresh
On 2007年2月28日, Suresh Pillai wrote:
> I posed the question below back in Nov, but never received a response.
> Thought I'd try again, as I really do need this kind of plot, and I don't
> want to leave the world of matplotlib, which has improved my efficiency
> greatly in plotting.
>
> Thanks,
> Suresh

I posed the question below back in Nov, but never received a response. 
Thought I'd try again, as I really do need this kind of plot, and I don't 
want to leave the world of matplotlib, which has improved my efficiency 
greatly in plotting.
Thanks,
Suresh
---------- Forwarded message ----------
I have a figure with two subplots as below. However, everything breaks
when I try to rotate the x-labels as indicated in the two commented-out
lines. I obtain a small empty plot embedded in a large empty plot with no
x-labels and no legend either. I got this code from the tutorial; it
works perfectly fine for the same data/commands if only using a single
main plot.
 pylab.subplot(211)
 pylab.plot(historicalScore05, label='Score 2005')
 pylab.plot(historialNum05, label='Num 2006')
 pylab.setp(pylab.gca(), xticklabels=[])
 pylab.ylabel('Score 2')
 pylab.title('Historical Statistics')
 pylab.legend(loc='upper left')
 pylab.subplot(212)
 pylab.plot(historicalScore06, label='Score 06')
 pylab.plot(historicalNum06, label='Num 06')
 pylab.xticks(dates)
 #xlabels = pylab.axes().get_xticklabels()
 #pylab.setp(xlabels, 'rotation', 90)
 pylab.xlabel('Player')
 pylab.ylabel('Score 1')
 pylab.legend(loc='upper left')
Any idea what is wrong?
numpy-1.0
matplotlib-0.87.7
Thanks,
Suresh

On 2/27/07, Christopher Barker <Chr...@no...> wrote:
> Or even more - not use pylab at all. There is nothing inherent in OO
> design that makes it necessary to write a bunch more code. It would be
> nice if the OO interface were just as easy to use.
I don't agree with this at all. Inherent in OO design is object
creation, attribute setting and method calling. pylab automates some
of these steps, which in any OO design can be a little repetitive, via
figure management and current axes handling. Consider this current
use case of pylab
 > ipython -pylab
 >>> plot([1,2,3])
A figure window pops up and a plot appears inside an axes. My belief
is that try as you might, you won't create an object oriented API
which mimics this ease of use. Let's say you are willing to grant
pylab (or whatever you call your favorite API) control of managing of
the current figure via use of a 'figure' call. Then you can simplify
this to
 >>> fig = figure()
 >>> ax = fig.add_subplot(111)
 >>> ax.plot([1,2,3])
OK, that's not too bad and is how I work on a daily basis, but it is
still considerably more typing. So let's grant automatic current
Figure creation to the API. We'll retain control of creating the
Axes, but if there is not a Figure window to put it into, we'll
automatically create a Figure to hold it. Then we have something like
 >>> ax = subplot(111) # automatically create a Figure to hold the Axes
 >>> ax.plot([1,2,3])
That's only a little more work (and is supported with 'from pylab
import subplot'), but why do we have to manually instantiate the Axes
with 'subplot', let's autocreate it if it isn't there. Ok, let's make
a function 'plot' that will plot into the current Axes if it exists
and create one if it isn't there (and by implication create a Figure
if it isn't there)
 >>> plot([1,2,3])
OK, that's nice and easy, but we just reinvented pylab 'plot', which
really does nothing except manage the current Axes and Figure and
forward the rest on to Axes.plot. pylab does nothing except manage
the boiler plate that comes from using an OO framework -- basically it
automates object instantiation and method calling by inferring which
objects you want to create and which objects you want to forward the
method calls to. And in my opinion, it does so pretty well.
In an OO framework, this process of inference and forwarding is
prevented by design, and hence you have more work to do on the user
end, usually for good reason. I believe there is a tradeoff between
having explicit control -- managing axes and figures and explicitly
designating which objects get the attribute assignments and method
calls -- and convenience. pylab trades explicit control, which is not
to say it trades control, for less boilerplate code and more
convenience. pylab is a state machine -- it manages the current
figure and axes and forwards calls as appropriate to the active object
-- and state machines have proven very useful in other programming
paradigms, For example, the postscript and opengl languages are both
state machines, not object oriented languages, and both are very
useful for creating graphics,
The point of this exercise is that you can make the API progressively
easier to use by providing helper functions, but in the end, you'll
rewrite pylab or something like it. In my experience, save for a
little boilerplate for figure and axes creation, and the occasional
verbosity of some getters and setters, the current OO API is pretty
easy to use.
The one thing that is clearly more verbose than it needs to be to me
is the use of the setters and getters. One wants to do
 o = ax.text(1, 2, 'hi Chris')
 o.color = 'black'
rather than
 o = ax.text(1, 2, 'hi Chris')
 o.set_color('black')
and we could implement that fairly easy, saving five keystrokes.
Probably the reason there is limited impetus to do so is that it is
even easier (and less typing) to use keyword args in the current API
(and in pylab since pylab just forwards them to the API)
 ax.text(1, 2, 'hi mom', color='black')
and in fact using multiple kwargs is a good bit less typing than using
multiple properties. Eg, the following which you can do currently
 ax.text(1, 2, 'hi mom', color='black', size=14)
is a good bit easier than
 o = ax.text(1, 2, 'hi Chris')
 o.color = 'black'
 o.size = 14
and so on.
You've made the point about the API being hard to use many times, and
at least once you've made specific suggestions (eg adding
Figure.savefig) which we've implemented and I which find quite
useful. I suggest you start a wiki page on the matplotlib Cookbook
site listing the problems you see with the API and specific things you
would like to see changed, so the discussion can be more productive.
JDH

Eric Firing wrote:
> make it as easy as possible for a person to do 
> something interactive in pylab and then translate it into a more 
> OO-style script.
Or even more - not use pylab at all. There is nothing inherent in OO
design that makes it necessary to write a bunch more code. It would be
nice if the OO interface were just as easy to use.
-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...

Mark Bakker wrote:
> John -
> 
> Maybe I misunderstand you, but I thought the pylab interface
> was invented to do very useful stuff (yet you want to prevent it
> from doing something useful ??).
No, the point is to minimize differences between pylab functions and 
object methods, to make it as easy as possible for a person to do 
something interactive in pylab and then translate it into a more 
OO-style script. The present "axis" function is an example--it is a 
wrapper around Axes.axis(). Evolution from a Matlab legacy has made 
"axis" rather clunky, so the idea of an "aspect" method and function is 
reasonable.
> 
> All the functionality is already in the API, but the calling sequence
> is too lengthy and somewhat convoluted for interactive use.
> The pylab interface is great for interactive use in my opinion.
> The proposed aspect command falls right into that framework.
> Eric suggested it a week or so ago, as he thought (and I agreed)
> that the axis command in pylab was doing too many things already.
Your implementation of aspect() does only a little more than 
Axes.set_aspect(), which is itself something of an anomaly among the 
"set_* commands (my fault). A little reorganizing may be in order; I'll 
look at that also.
Sorry to be sluggish on this.
> 
> Mark
> 
> 
> On 2/27/07, *John Hunter* <jd...@gm... <mailto:jd...@gm...>> 
> wrote:
> 
> On 2/27/07, Mark Bakker <ma...@gm...
> <mailto:ma...@gm...>> wrote:
> > Thanks for the explanation, John.
> > I printed out the CODING_GUIDE (sorry, didn't know it existed).
It is very new.
> > The new function with the extra copy command is shown below.
> > Can we add this to pylab?
> 
> Since Eric has been developing and maintaining the aspect stuff of
> late, I'll leave it to him to review and contribute. My one comment
> is I want to make pylab as thin a wrapper as possible and where
> possible prevent it from doing anything useful. That is, I'd like to
> see all the functionality in the API, and the pylab calls simply make
> the appropriate forwarding calls. Is there a reason all of this
> cannot be done in the relevant Axes methods, with the pylab call
> simply forwarding on the *args and **kwargs?
This is what I had in mind.
> 
> Thanks,
> JDH
> 
> 

On 2/27/07, Sture Lygren <st...@ro...> wrote:
> Thanks a lot for your reply. I still have some problem tough. I want
> vertical alignment of 5 ylabels for 5 different subplots. Trying your
> solution I'm able to move the ylabels up/down but not right/left. Seems
> like changing 'x' in position (x,y) has no effect at all. How come?
The ylabel position is layed out to not overlay the y tick labels --
if these are in different positions on each axes you will get the
ylabel in different positions. Two solutions:
 1) insure all the yticklabels have the same width by using a custom
formatter that fixes the tick widths.
 from matplotlib.ticker import FormatStrFormatter
 ax.yaxis.set_major_formatter(FormatStrFormatter('%1.3f'))
 2) do not use ylabels, but create your own using custom text
instances for labels
 ax.text(-0.1, 0.5, 'my label', transform=ax.transAxes, rotation=90,
ha='right', va='center')
The 2nd one is probably what you want.
JDH

Should be horizontal alignment ...
Sture Lygren wrote:
> Hi,
> 
> Thanks a lot for your reply. I still have some problem tough. I want
> vertical alignment of 5 ylabels for 5 different subplots. Trying your
> solution I'm able to move the ylabels up/down but not right/left. Seems
> like changing 'x' in position (x,y) has no effect at all. How come?
> 
> regards,
> Sture
> 
> Jouni K. Seppänen wrote:
>> Sture Lygren <st...@ro...> writes:
>>
>>> Quick question - how can I align ylabels for several subplots?
>> Set their position properties e.g. like this:
>>
>> y = ylabel('foo')
>> pos = getp(y, 'position')
>> setp(y, 'position', (pos[0], X))
>>
>> where X is the position (in data coordinates) where you want the
>> label. Depending on what kind of alignment you want, you may want to
>> set the verticalalignment property -- to see the properties and the
>> kind of values they can take, type setp(y), and to see their current
>> values, type getp(y).
>>
>> If your subplots have different scales, you will want to set the
>> transform property, which is a little bit more complicated; there 
>> are examples at
>>
>> http://www.scipy.org/Cookbook/Matplotlib/Transformations 
>>
> 
-- 
Sture Lygren
Computer Systems Administrator
Andoya Rocket Range
Work: +4776144451 / Fax: +4776144401

Hi,
Thanks a lot for your reply. I still have some problem tough. I want
vertical alignment of 5 ylabels for 5 different subplots. Trying your
solution I'm able to move the ylabels up/down but not right/left. Seems
like changing 'x' in position (x,y) has no effect at all. How come?
regards,
Sture
Jouni K. Seppänen wrote:
> Sture Lygren <st...@ro...> writes:
> 
>> Quick question - how can I align ylabels for several subplots?
> 
> Set their position properties e.g. like this:
> 
> y = ylabel('foo')
> pos = getp(y, 'position')
> setp(y, 'position', (pos[0], X))
> 
> where X is the position (in data coordinates) where you want the
> label. Depending on what kind of alignment you want, you may want to
> set the verticalalignment property -- to see the properties and the
> kind of values they can take, type setp(y), and to see their current
> values, type getp(y).
> 
> If your subplots have different scales, you will want to set the
> transform property, which is a little bit more complicated; there 
> are examples at
> 
> http://www.scipy.org/Cookbook/Matplotlib/Transformations 
> 
-- 
Sture Lygren
Computer Systems Administrator
Andoya Rocket Range
Work: +4776144451 / Fax: +4776144401

John -
Maybe I misunderstand you, but I thought the pylab interface
was invented to do very useful stuff (yet you want to prevent it
from doing something useful ??).
All the functionality is already in the API, but the calling sequence
is too lengthy and somewhat convoluted for interactive use.
The pylab interface is great for interactive use in my opinion.
The proposed aspect command falls right into that framework.
Eric suggested it a week or so ago, as he thought (and I agreed)
that the axis command in pylab was doing too many things already.
Mark
On 2/27/07, John Hunter <jd...@gm...> wrote:
>
> On 2/27/07, Mark Bakker <ma...@gm...> wrote:
> > Thanks for the explanation, John.
> > I printed out the CODING_GUIDE (sorry, didn't know it existed).
> > The new function with the extra copy command is shown below.
> > Can we add this to pylab?
>
> Since Eric has been developing and maintaining the aspect stuff of
> late, I'll leave it to him to review and contribute. My one comment
> is I want to make pylab as thin a wrapper as possible and where
> possible prevent it from doing anything useful. That is, I'd like to
> see all the functionality in the API, and the pylab calls simply make
> the appropriate forwarding calls. Is there a reason all of this
> cannot be done in the relevant Axes methods, with the pylab call
> simply forwarding on the *args and **kwargs?
>
> Thanks,
> JDH
>

On 2/27/07, Mark Bakker <ma...@gm...> wrote:
> Thanks for the explanation, John.
> I printed out the CODING_GUIDE (sorry, didn't know it existed).
> The new function with the extra copy command is shown below.
> Can we add this to pylab?
Since Eric has been developing and maintaining the aspect stuff of
late, I'll leave it to him to review and contribute. My one comment
is I want to make pylab as thin a wrapper as possible and where
possible prevent it from doing anything useful. That is, I'd like to
see all the functionality in the API, and the pylab calls simply make
the appropriate forwarding calls. Is there a reason all of this
cannot be done in the relevant Axes methods, with the pylab call
simply forwarding on the *args and **kwargs?
Thanks,
JDH

On 2/27/07, Bart van Kuik <b.v...@sr...> wrote:
> Hi guru's,
>
> I'm using the LineCollection class because I colorize my line segments
> (the color is essentially a third dimension in the plot). However, I'd
> like a marker on the line points. Any suggestions on methods/attributes,
> or which other class to use?
If you are using homogeneous markers (same color, size and shape),
just use "plot" to create a line with markers of the desired style
 ax.plot(x, y, 'o')
If you want different colored markers, use scatter (which creates a
RegularPolyCollection).
JDH

On 2/27/07, Berthold H=F6llmann <ber...@de...> wrote:
> The online documentation on
> <http://matplotlib.sourceforge.net/matplotlib.axes.html> marks the
> method 'get_child_artists' deprecated. What else can I use instead?
Use ax.get_children in matplotlib-0.90 and svn.
JDH

The online documentation on
<http://matplotlib.sourceforge.net/matplotlib.axes.html> marks the
method 'get_child_artists' deprecated. What else can I use instead?
Thanks
Berthold
-- 
 __ Address:
 G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg

Thanks for the explanation, John.
I printed out the CODING_GUIDE (sorry, didn't know it existed).
The new function with the extra copy command is shown below.
Can we add this to pylab?
Thanks, Mark
def aspect(*args, **kwargs):
 """
 Set/Get the aspect ratio (ylength/xlength) of the current axis
 Aspect ratio is defined as unit-length-along-y-axis /
unit-length-along-x-axis
 If no arguments are passed, the current aspect ratio is returned
 Aspect ratio may be met by changing size of axes while keeping data
limits fixed (called 'box'),
 or by changing data limits while keeping the lengths of the axes fixed
(called 'datalim')
 One point remains fixed, which is called the anchor, for example the
center (called 'C')
 Autoscaling may be turned on (limits may change upon next plotting
command)
 or off (limits will remain fixed)
 Keyword arguments:
 adjustable: 'box' (default), 'datalim'
 anchor: 'C' (default), 'SW', 'S', 'SE', 'E', 'NE', 'N', 'NW', 'W'
 fixlim: True (default), False
 """
 ax = gca()
 if len(args)==0:
 aspect = ax.get_aspect()
 elif len(args)==1:
 aspect = args[0]
 kwargs = kwargs.copy()
 adjustable = popd(kwargs,'adjustable','box')
 anchor = popd(kwargs,'anchor','C')
 fixlim = popd(kwargs,'fixlim',True)
 ax.set_aspect(aspect,adjustable,anchor)
 if fixlim:
 ax.set_autoscale_on(False)
 else:
 ax.set_autoscale_on(True)
 ax.autoscale_view()
 draw_if_interactive()
 return aspect
On 2/26/07, John Hunter <jd...@gm...> wrote:
>
> On 2/26/07, Mark Bakker <ma...@gm...> wrote:
>
> > ax = gca()
> > if len(args)==0:
> > aspect = ax.get_aspect()
> > elif len(args)==1:
> > aspect = args[0]
> > adjustable = popd(kwargs,'adjustable','box')
> > anchor = popd(kwargs,'anchor','C')
> > fixlim = popd(kwargs,'fixlim',True)
>
> Whenever you are mutating a kwargs dictionary, eg with popd, you
> should first copy it. The user may be creating, saving, and resuing a
> kwarg dict
>
> myaspectprops = dict(adjustable='box', anchor='NW')
> # some code
> aspect(**myaspectprops)
> # some more code
> aspect(**myaspectprops)
>
> This will fail if you pop off of the kwargs in the aspect function w/o
> first copying it. So always do
>
> kwargs = kwargs.copy()
>
> before calling popd and friends.
>
> This is covered in the "CODING_GUIDE" document in the svn repository.
>
> JDH
>

Lionel Roubeyrie <lro...@li...> writes:
> Oups, sorry for the mistake, the Vera font in the resulting pdf file from 
> epstopdf is effectively converted to T3Font_0 Type 3. 
> You can have a look here:
> http://www.limair.asso.fr/share/pre2.eps and
> http://www.limair.asso.fr/share/pre2.pdf
The Type 3 font is present in the eps file, so it is not created by
the conversion to pdf. Perhaps it is an artifact of the "distilling"
done by matplotlib; if you set ps.usedistiller to None, what does the
eps file look like?
Somehow the Cmr and Cmmi fonts survive as TrueType. One quick
workaround for your problem could be to turn all text into mathtext:
replace e.g. "février" by r"$\rm{f\'evrier}$" and for the yticklabels
do something like (caveat: untested code)
 for x in getp(gca(), 'yticklabels'):
 setp(x, 'text', r'$\rm{%s}$' % getp(x, 'text'))
(Or is there an easier way to select Computer Modern Roman as the
font?)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks for the tips Nicolas, I'm going to switch to SVN and try your patch.
Le Lundi 26 F=C3=A9vrier 2007 19:33, Nicolas Grilly a =C3=A9crit=C2=A0:
> On 2/26/07, Lionel Roubeyrie <lro...@li...> wrote:
> > I just want to set xlabels with :
> > MOIS=3D['janvier',
> > u'f=C3=A9vrier', 'mars', 'avril', 'mai', 'juin', 'juillet', 'aout',
> > 'septembre', 'octobre', 'novembre', u'd=C3=A9cembre']
> > resulting in 'f?vrier' and 'd?cembre' in the pdf file.
>
> Ok. This is exactly what I do with matplotlib, but I use the most
> recent version checked out from Subversion repository. Can you install
> matplotlib on your system, directly from Subversion, and test your
> script again?
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
=2D-=20
Lionel Roubeyrie - lro...@li...
Chag=C3=A9 d'=C3=A9tudes et de maintenance
LIMAIR - la Surveillance de l'Air en Limousin
http://www.limair.asso.fr

Oups, sorry for the mistake, the Vera font in the resulting pdf file from=20
epstopdf is effectively converted to T3Font_0 Type 3.=20
You can have a look here:
http://www.limair.asso.fr/share/pre2.eps and
http://www.limair.asso.fr/share/pre2.pdf
Thanks
Le Lundi 26 F=E9vrier 2007 19:38, Jouni K. Sepp=E4nen a =E9crit=A0:
> Lionel Roubeyrie <lro...@li...> writes:
> > Fonts are BitStream VeraSans-Roman, TrueType.
>
> Then this is not the usual font problem where fonts get converted
> either into Type 3 or into raw drawing commands. Can you put example
> files (both eps and pdf) on some website so we can try to understand
> what is wrong with them?
=2D-=20
Lionel Roubeyrie - lro...@li...
Chag=E9 d'=E9tudes et de maintenance
LIMAIR - la Surveillance de l'Air en Limousin
http://www.limair.asso.fr

Sture Lygren <st...@ro...> writes:
> Quick question - how can I align ylabels for several subplots?
Set their position properties e.g. like this:
 y = ylabel('foo')
 pos = getp(y, 'position')
 setp(y, 'position', (pos[0], X))
where X is the position (in data coordinates) where you want the
label. Depending on what kind of alignment you want, you may want to
set the verticalalignment property -- to see the properties and the
kind of values they can take, type setp(y), and to see their current
values, type getp(y).
If your subplots have different scales, you will want to set the
transform property, which is a little bit more complicated; there 
are examples at
 http://www.scipy.org/Cookbook/Matplotlib/Transformations 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi guru's,
I'm using the LineCollection class because I colorize my line segments 
(the color is essentially a third dimension in the plot). However, I'd 
like a marker on the line points. Any suggestions on methods/attributes, 
or which other class to use?
Thanks,
Bart van Kuik

Hi,
Quick question - how can I align ylabels for several subplots?
Sture
-- 
Sture Lygren
Computer Systems Administrator
Andoya Rocket Range
Work: +4776144451 / Fax: +4776144401

On 2007年2月26日, kc1...@ya... apparently wrote: 
> gs didn't seen to complain.
That increases the likelihood it is the MS interpreter.
Odd thought.
> I also tried GIMP. While it didn't complain, the picture 
> displayed is horribly bad. 
IIRC, that would be a bitmap of your file ...
Cheers,
Alan Isaac

On 2/26/07, Mark Bakker <ma...@gm...> wrote:
> ax = gca()
> if len(args)==0:
> aspect = ax.get_aspect()
> elif len(args)==1:
> aspect = args[0]
> adjustable = popd(kwargs,'adjustable','box')
> anchor = popd(kwargs,'anchor','C')
> fixlim = popd(kwargs,'fixlim',True)
Whenever you are mutating a kwargs dictionary, eg with popd, you
should first copy it. The user may be creating, saving, and resuing a
kwarg dict
 myaspectprops = dict(adjustable='box', anchor='NW')
 # some code
 aspect(**myaspectprops)
 # some more code
 aspect(**myaspectprops)
This will fail if you pop off of the kwargs in the aspect function w/o
first copying it. So always do
 kwargs = kwargs.copy()
before calling popd and friends.
This is covered in the "CODING_GUIDE" document in the svn repository.
JDH