matplotlib-users Mailing List for matplotlib (Page 7)

Hi again,

while browsing the docs about axes, I found this example, which seems to be a 
recurrent "pattern" each time one wants to draw subplots in a figure:

cnt = 0
for i in range(numRows):
      for j in range(numCols):
           cnt+=1
           ax=subplot(numRows,numCols,cnt)
           plot(blah,blah)
           if ax.is_last_row() : xlabel('time(s)')
           if ax.is_first_col(): ylabel('volts')

Indeed, I've written such code many times now. It seems to me that the use of 
subfigures could be make easier with such "subplots" function as:

for ax in subplots(numRows,numCols):
    plot(blah,blah)
    if ax.is_last_row() : xlabel('time(s)')
    if ax.is_first_col(): ylabel('volts')

What do you think ?

On Monday 13 June 2005 17:51, John Hunter wrote:
> I think you may be misunderstanding something.  axes and subplot are
> both helper functions to create an Axes instance.  You should use one
> or the other to create a given Axes, but should not use "axes" before
> "subplot" in order to change the behavior of subplot.
>

Yes, you were right, I was a bit confused by this axes stuff, which is now 
clearer to me. Thanks !

Still, I have the feeling that having both an Axis and an Axes class, while 
"axes" is the plural of "axis", might be a bit confusing


> If you do not like the way the Axes are laid out when using subplot,
> you have to do the layout manually with axes.  There have been some
> helper functions and code posted on the mailing list archives to make
> this process easier (eg a tk backend GUI widget to help you configure
> subplots).
>

OK, I didn't find them but will try further.

Anyway, subfigures are drawn with a certain margin between each other, which 
must take the form of either a hardcoded constant in the source code, or a 
variable. Exposing this constant/variable to the user would allow him to 
easily change it, which sounds useful to me ;-)

I've looked into the axes-related source code for that constant/variable, but 
couldn't find it...

cheers,
nicolas

On Monday 13 June 2005 22:57, John Hunter wrote:
> Are you using the same tick locator on different axes? 

Thanks for your answer ; yes, I am

> You shouldn't be.  

Oh, really ? Then it must be that. Let me try... OK, I used

  a.yaxis.set_major_locator(LinearLocator(numticks=3))

instead of reusing the same locator, and here's the result:

  http://nicolasgirard.nerim.net/3ticks.png

As you can see, there's a big improvement but still a problem with the 
subplots on the right.

I'd suggest add to the docs the fact that a locator shouldn't be reused, 
because it's not obvious, since a valid semantics is:

  majorLocator = LinearLocator(numticks=3)
  ...
  anAxis.set_major_locator(majorLocator)

which I understood as:

  "anAxis's locator should be linear, with 3 ticks"


> You should try and create a standalone script that exposes your 
> bug.

Okay, I'll do it, but perhaps not before the next week-end...

cheers,
nicolas

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:

    Nicolas> On Friday 10 June 2005 00:13, Nicolas Girard wrote:
    >> There's an other annoying bug with this script. For the
    >> subplots on columns 2 and 3 I asked the yaxis to have only but
    >> 3 ticks, using:
    >> 
    >> majorLocator = LinearLocator(numticks=3)
    >> 
    >> ...  a=subplot(nbvals,3,i)
    >> a.yaxis.set_major_locator(majorLocator)
    >> 
    >> which works, but as the figure gets refreshed, the ticks
    >> disappear, and at the end only part of them remain
    >> visible. I've encounetered this with the standard Agg backend,
    >> with either interactive and non-interactive mode.  Saving as
    >> jpeg, png and ps didn't help, as you can see here:
    >> 
    >> http://nicolasgirard.nerim.net/out.png
    >> 
    >> 
    Nicolas> Unfortunately, this problem remains, even after updating
    Nicolas> my sandbox and trying Baptiste Carvello's patch :-/

Are you using the same tick locator on different axes?  You shouldn't
be.  You should try and create a standalone script that exposes your
bug.

JDH

Kevin,

Please try mpl version 0.81 and the current basemap package.  There were 
big changes in contourf and routines it uses between 0.80 and 0.81.

Eric

On Friday 10 June 2005 00:13, Nicolas Girard wrote:
> There's an other annoying bug with this script. For the subplots on columns
> 2 and 3 I asked the yaxis to have only but 3 ticks, using:
>
>   majorLocator   = LinearLocator(numticks=3)
>
>   ...
>   a=subplot(nbvals,3,i)
>   a.yaxis.set_major_locator(majorLocator)
>
> which works, but as the figure gets refreshed, the ticks disappear, and at
> the end only part of them remain visible. I've encounetered this with the
> standard Agg backend, with either interactive and non-interactive mode.
> Saving as jpeg, png and ps didn't help, as you can see here:
>
> http://nicolasgirard.nerim.net/out.png
>
>
Unfortunately, this problem remains, even after updating my sandbox and trying  
Baptiste Carvello's patch :-/

cheers,
nicolas

On Monday 13 June 2005 17:33, John Hunter wrote:
> Your problem is here:
>
>   setp(a.get_yticklabels(), visible=False)
>
> By making your yticklabels invisible, they are still used in
> determining the position of the ylabel, but they aren't displayed
> (this may be a mpl bug, I haven't thought about it enough).  What you
> want to do is turn off the tick labels altogether.
>
>   ax.set_yticklabels([])
>

John,
thanks for your answer : it solved the problem !

cheers,
nicolas

>>>>> "John" == John Hunter <jdh...@ac...> writes:

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
    Arnd> If there is a simpler way to achieve this, I would of course
    Arnd> be interested.  In general I think it would be nice to
    Arnd> change the joinstyle with a simple command, either globally
    Arnd> or even better on a line-by-line basis.  Is this possible
    Arnd> already now in some way?

    John> There is no better way.  I have been holding off on exposing
    John> this because I didn't see a clear way to handle it because
    John> dashed and solid lines have different default cap and join
    John> styles.  It is now clear that c good solution is to expose
    John> dash_capstyle, dash_joinstyle, solid_capstyle,
    John> solid_joinstyle, as rc params and line properties.

    John> Any forseeable problems with this approach?

Hey Arnd,

OK, I went ahead with this approach (lines.py CVS revision 1.32 or
later).  Only lightly tested.  I'm already having fun with the new
kwargs to axes, as this testscript illustrates

    from pylab import *

    rc('lines', lw=3)
    y = [0.1, 0.9, 0.1, 0.9]

    axd = dict(xlim=(0,2), ylim=(0,1), autoscale_on=False)

    ax1 = subplot(311, **axd)
    plot(y, solid_joinstyle='miter')

    axd.update(dict(sharex=ax1, sharey=ax1))

    subplot(312, **axd)
    plot(y, solid_joinstyle='round')

    subplot(313, **axd)
    plot(y, solid_joinstyle='bevel')


    show()

JDH

On 6/13/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Dave" =3D=3D Dave  <da...@gm...> writes:
>=20
>    Dave> I'm getting a "crash" when using ipython and pylab on WinXP.
>    Dave> The problem shows up when I have a subplot and try to use
>    Dave> ylim to change the axis scale.  Here's an example (after
>    Dave> plotting some data).
>=20
>    Dave> In [2]: ylim() Out[2]: (0.0, 30000000000.0)
>=20
>    Dave> In [3]: xlim(-6, 6) Out[3]: (-6, 6)
>=20
>    Dave> (axis scsale changes as expected)
>=20
>    Dave> In [4]: ylim(0, 1000)
>=20
>    Dave> ( crash - i.e., CPU use goes to 100%, prompt does not
>    Dave> return, Tkinter and ipython windows unresponsive)
>=20
>=20
> My guess is that you have data at 30000000000.0 and when you zoom in
> to 1000 the data is so far out of the view lim that it is overflowing
> an integer in the extension code.  This is a know bug, but if you post
> a complete example on the sf site in the bug report section that
> exposes us, it will help us fix it sooner rather than later.
>=20
> Thanks,
> JDH
>=20


I'll see if I can reproduce it wirth a nice simple example suitable
for debug.  If so I'll post to sf.  Thanks.

By the way, the new autoscale flag will be used and appreciated here
just as soon as I can add it to my scripts.

- David

If anyone could assist me in understanding what issues result in the error 
message below , I would be very grateful.

"Cannot automatically convert masked array to Numeric because data
                   is masked in one or more locations"
(error raised by Numeric, but within matplotlib core)

I frequently run into this error message when I try to use matplotlib to 
produce contour graphs.  Does anyone have a more detailed explanation of what 
issues prompt this error?  What confuses me is that the same script (posted 
below, FWIW) may or may not produce this error depending on which datafile I 
try to graph?  I also get this message if I use the Numeric function where() 
to generate any array used by the contour() function.

Thanks,
    Kevin Mueller
    Univ. Illinois, Dept. Atmospheric Sciences, Urbana/Champaign

#######################

traceback:
(python 2.4.1, Numeric 24b, matplotlib 0.80, linux)

#######################

Traceback (most recent call last):
  File "/home/manabe/a/kjmuelle/scripts/latlonslice.py", line 39, in ?
    badmask=outmask,cmap=cm.jet,colors=None)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py", 
line 1030, in contourf
    levels, colls = pylab.contourf(*args, **kwargs)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/pylab.py", 
line 1679, in contourf
    ret =  gca().contourf(*args, **kwargs)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/axes.py", 
line 1248, in contourf
    return self._contourHelper.contourf(*args, **kwargs)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/contour.py", 
line 879, in contourf
    lev, cmap)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/contour.py", 
line 629, in _process_colors
    mappable.autoscale()
  File "/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/cm.py", 
line 456, in autoscale
    self.norm.autoscale(self._A)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/colors.py", 
line 580, in autoscale
    rval = ravel(A)
  File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/Numeric/Numeric.py", 
line 543, in ravel
    return reshape(m, (-1,))
  File "/home/manabe/a/kjmuelle/lib/python2.4/site-packages/Numeric/MA/MA.py", 
line 632, in __array__
    raise MAError, \
MA.MA.MAError: Cannot automatically convert masked array to Numeric because 
data
                   is masked in one or more locations.

############################

WHEN RUNNING THIS SCRIPT:

############################

from Scientific.IO import NetCDF as nc
import Numeric as nm
from pylab import *
import sys,os.path


it=0 # time index
ik=0 # depth index
tracer="DIC" # tracer name

if not len(sys.argv)>1:
    print "Error: no datafile arguments given"
else:
    datapaths = sys.argv[1:]

for datapath in datapaths:
    f = nc.NetCDFFile(datapath)
    outdata = f.variables[tracer].getValue()[it,ik,:,:]
    outmask = f.variables["TMASK"].getValue()[ik,:,:]
    gdepth = f.variables["z_t"].getValue()
    f.close()

    X,Y,Z = nm.arange(-180,181,4),nm.arange(-90,91,2),gdepth*.01

    clf()

    levels,colors = contourf(X,Y,outdata,
                               badmask=outmask,cmap=cm.jet,colors=None)
    levels,colors = contour(X,Y,outdata,
                              badmask=outmask,colors='k')
    colorbar(tickfmt="%.1e")

    gtitle = "%s: at depth %i, %s" % (os.path.split(datapath[1],-Z[ik],tracer)
    title(gtitle)
    show()

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

    Arnd> If there is a simpler way to achieve this, I would of course
    Arnd> be interested.  In general I think it would be nice to
    Arnd> change the joinstyle with a simple command, either globally
    Arnd> or even better on a line-by-line basis.  Is this possible
    Arnd> already now in some way?

There is no better way.  I have been holding off on exposing this
because I didn't see a clear way to handle it because dashed and solid
lines have different default cap and join styles.  It is now clear
that c good solution is to expose dash_capstyle, dash_joinstyle,
solid_capstyle, solid_joinstyle, as rc params and line properties.

Any forseeable problems with this approach?

JDH

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

    Arnd> Well, difficult to estimate from my side, as I don't know
    Arnd> how much extra code it would be.
    >> From a (=my) user perspective I think it would be nice,
    Arnd> because I have a couple of situations where one plot should
    Arnd> stay with the same range in x and y whereas another plot
    Arnd> next to it should autoscale.

Perhaps then the best solution is just to expose that property (and
all other axes properties) in the subplot and axes functions.  This
seems like the cleanest, easiest implementation to me.  I just checked
this into CVS (axes.py revision 1.112).

So you can do, eg, 

   subplot(111, autoscale_on=False)

As usual, you get a quick synopsis of settable props, you can do


In [2]: ax = gca()

In [3]: setp(ax)
    alpha: float
    autoscale_on: True|False
    axis_bgcolor: any matplotlib color - see help(colors)
    axis_off: void
    axis_on: void
    clip_box: a matplotlib.transform.Bbox instance
    clip_on: [True | False]
    cursor_props: a (float, color) tuple
    figure: a Figure instance
    frame_on: True|False
    label: any string
    lod: [True | False]
    position: len(4) sequence of floats
    title: str
    transform: a matplotlib.transform transformation instance
    visible: [True | False]
    xlabel: str
    xlim: len(2) sequence of floats
    xscale: str
    xticklabels: sequence of strings
    xticks: sequence of floats
    ylabel: str
    ylim: len(2) sequence of floats
    yscale: str
    yticklabels: sequence of strings
    yticks: sequence of floats
    zorder: any number


Thus you can do now do fun things like

  subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
          xlim=(-1,1), ylim =(0,10) )

Very nice!
JDH

On Mon, 13 Jun 2005, John Hunter wrote:

> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
>
>     Arnd> Just one more question on this: is there an even simpler way
>     Arnd> to activate this than via fig = figure(figsize=(6,6)) ax =
>     Arnd> fig.add_axes([0.1, 0.1, 0.8, 0.8])
>     Arnd> ax.set_autoscale_on(False) ?  For example, could one apply a
>     Arnd> general autoscale(False) to the following plot(s)/subplots?
>
> I can think of two ways this could be implemented.  Make it an rc
> property, and when any new axes are created they would use the rc
> default.

Personally I don't use rc properties much, only if I can't avoid
them (Reasoning: I want to keep my plot-files portable
from one machine to the other without carrying the rc files
around. Setting rc properties from within the programm
is an alternative, but not _my_ preferred  one).

> Alternatively, one could make it a figure method, which
> would apply to all of its axes.  Eg if you did
>
>   fig.autoscale(False)
>
> then autoscaling would be turned off on all existing axes and would be
> off by default for any new ones created.

I do like this one - does this also mean that autoscale=False
can be given as additional argument to the figure command?
In addition it would be nice to set this type of option
for the subplot command.

> I am not sure if this is a sufficiently useful configuration option to
> justify the extra code.  What do you think?

Well, difficult to estimate from my side, as I don't know how
much extra code it would be.
From  a (=my) user perspective I think it would be nice,
because I have a couple of situations
where one plot should stay with the same range in x and y
whereas another plot next to it should autoscale.

Best,

Arnd

>>>>> "Dave" == Dave  <da...@gm...> writes:

    Dave> I'm getting a "crash" when using ipython and pylab on WinXP.
    Dave> The problem shows up when I have a subplot and try to use
    Dave> ylim to change the axis scale.  Here's an example (after
    Dave> plotting some data).

    Dave> In [2]: ylim() Out[2]: (0.0, 30000000000.0)

    Dave> In [3]: xlim(-6, 6) Out[3]: (-6, 6)

    Dave> (axis scsale changes as expected)

    Dave> In [4]: ylim(0, 1000)

    Dave> ( crash - i.e., CPU use goes to 100%, prompt does not
    Dave> return, Tkinter and ipython windows unresponsive)


My guess is that you have data at 30000000000.0 and when you zoom in
to 1000 the data is so far out of the view lim that it is overflowing
an integer in the extension code.  This is a know bug, but if you post
a complete example on the sf site in the bug report section that
exposes us, it will help us fix it sooner rather than later.

Thanks,
JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Hi all, rc('l',lw=1,mew=0,markersize=1)

Ficed in CVS -- I simply removed the abbrevs for the toplevel rc.  Eg,
'lw' is still an 'abbrev for 'linewidth' but 'l' is not an abbrev for
'lines'.  Since this wasn't working anyway, it won't break anyone's
code to "fix" it.

JDH

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

    Arnd> Just one more question on this: is there an even simpler way
    Arnd> to activate this than via fig = figure(figsize=(6,6)) ax =
    Arnd> fig.add_axes([0.1, 0.1, 0.8, 0.8])
    Arnd> ax.set_autoscale_on(False) ?  For example, could one apply a
    Arnd> general autoscale(False) to the following plot(s)/subplots?

I can think of two ways this could be implemented.  Make it an rc
property, and when any new axes are created they would use the rc
default.  Alternatively, one could make it a figure method, which
would apply to all of its axes.  Eg if you did

  fig.autoscale(False)

then autoscaling would be turned off on all existing axes and would be
off by default for any new ones created.  

I am not sure if this is a sufficiently useful configuration option to
justify the extra code.  What do you think?

JDH

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:

    Nicolas> Hi all, well, I'm sorry to wake up an old thread, but
    Nicolas> what if there are subplots in the figure ? I tried to ask

    Nicolas>   axes([0.1, 0.1, 0.9, 0.9])

    Nicolas> before specifying my subplot()s, but it changed nothing.

    Nicolas> How to reduce the margin of the whole figure when it has
    Nicolas> subplots ?

I think you may be misunderstanding something.  axes and subplot are
both helper functions to create an Axes instance.  You should use one
or the other to create a given Axes, but should not use "axes" before
"subplot" in order to change the behavior of subplot.

If you do not like the way the Axes are laid out when using subplot,
you have to do the layout manually with axes.  There have been some
helper functions and code posted on the mailing list archives to make
this process easier (eg a tk backend GUI widget to help you configure
subplots).

JDH

Your problem is here:

  setp(a.get_yticklabels(), visible=False)

By making your yticklabels invisible, they are still used in
determining the position of the ylabel, but they aren't displayed
(this may be a mpl bug, I haven't thought about it enough).  What you
want to do is turn off the tick labels altogether.

  ax.set_yticklabels([])

Hope this helps,
JDH

On Sunday 12 June 2005 11:56 am, Darren Dale wrote:
> cf...@li... wrote:
> >Looks like a problem with drawing ticks. Attached is code that
> > demonstrates the problem (for me), and the traceback.
> >
> >I'm using Python 2.4.1, Numeric 23.8, and the stock .matplotlibrc, on
> > win32.

A bug was reported for MPL-0.81. You will get the following error if an axi=
s=20
has only one tick located at 0.0:

> =A0File "C:\Python24\Lib\site-packages\matplotlib\ticker.py", line 323, i=
n=20
_set_orderOfMagnitude
> =A0 =A0else: oom =3D math.floor(math.log10(locs[-1]))
>OverflowError: math range error

The fix is in CVS. If you get don't have access to CVS, you can replace lin=
es=20
322 and 323:

            if locs[0] > locs[-1]: oom =3D math.floor(math.log10(locs[0]))
            else: oom =3D math.floor(math.log10(locs[-1]))

with

            if locs[0] > locs[-1]: val =3D locs[0]
            else: val =3D locs[-1]
            if val =3D=3D 0: oom =3D 0
            else: oom =3D math.floor(math.log10(val))


Darren

Dear John,

On Mon, 6 Jun 2005, John Hunter wrote:

> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
>
>     Arnd> So the question is, how can I turn off auto-scaling and just
>     Arnd> leave the plot window to the specified rectangle
>     Arnd> [-1.1,1.1]^2 ?
>
> No way in the current release.  But it is a good idea so I just added
> the "autoscale_on" property to the Axes, which you can use like
>
>   ax.set_autoscale_on(False)

Great, I just updated to 0.81  - it works fantastic!

> Thanks for the suggestion,

Well, I have to thank you for implementing this
(much faster than I could test this ;-).

Just one more question on this:
is there an even simpler way to activate
this than via
   fig = figure(figsize=(6,6))
   ax = fig.add_axes([0.1, 0.1, 0.8, 0.8])
   ax.set_autoscale_on(False)
?
For example, could one apply a general
  autoscale(False)
to the following plot(s)/subplots?

Many thanks,

Arnd

On Mon, 6 Jun 2005, Arnd Baecker wrote:

> Hi,
>
> What is the best way to change the joinstyle of lines?
> I found in the users guide for 0.80 (April 2005)
> that there is something like
>   gc.set_joinstyle('miter')
> but I don't know how to get to the gc from the pylab interface.

I tried out various further variants
(E.g.
  from matplotlib import rcParams
  rcParams['lines.joinstyle'] = 'bevel'     # 'miter', 'round', 'bevel'
  from pylab import *
)
but without success.

So for the moment I just modified backend_bases.py
in line 399 in the __init__ routine of
GraphicsContextBase
  self._joinstyle = 'bevel'  # 'miter

Now the lines are as I need them for my particular application.

If there is a simpler way to achieve this, I would of course
be interested.
In general I think it would be nice to change the
joinstyle with a simple command, either globally
or even better on a line-by-line basis.
Is this possible already now in some way?

Best,

Arnd

Hi John and Andrea,

John Hunter wrote:

>>>>>>"andrea" == andrea gavana <and...@ti...> writes:
> 
> 
>     andrea> Hello John & NG, I have just downloaded matplotlib 0.81,
>     andrea> and I am having some problems with the ToolBar. The "Back"
>     andrea> and "Forward" icons in the ToolBar2 are not shown. The
>     andrea> buttons are completely grey and they seem inactive. Is
>     andrea> this the expected behavior? I think it is not.  However,
>     andrea> my configuration is:
> 
>     andrea> - Windows XP - wxPython 2.6.1.0 - MatPlotLib 0.81 - WXAgg
>     andrea> backend - ToolBar2
> 
> This is a feature and a bug.  The feature part is that Werner Bruhin
> added a patch to "gray out" the forward and back buttons when clicking
> them produces no effect.  Eg, if there is no back (your first view of
> the figure) the button should be grayed out.  If you navigate
> somewhere, the button will be enabled.
The grey square is due to using "xpm" file formats for the button images 
(disabled state).

Attached is a version backend_wx.py which uses "png" files for the
"back" and "forward" button.  In theory this should show a black & white
version of the button when it is disabled (applying the alpha channel,
only supported by wx with png files).

However for whatever reason this does not work with matplotlib's
toolbar, it works very nicely when I create a test toolbar (see the
image sent with my previous mail on this thread, or run the attached 
wx_cursor_demoToolbar.py using the attached backend_wx.py).

I tried to narrow it down but but up to now without any luck.

I attached a demo file which shows how the button should look (hacked 
together toolbar with only back and forward button).  If you change the 
two lines below in the demo (comment the myadd_toolbar line and 
uncomment the other one you will get the normal matplotlib toolbar, but 
the disable button stuff doesn't work.

##        self.add_toolbar()  # comment this out for no toolbar
         self.myadd_toolbar()

Maybe someone else who know matplotlib better then I do might have an 
idea on what is going on.

See you
Werner
> 
> The bug is that on win32 with wxpython 2.6.1 instead of presenting a
> grayed out version of the button the button is a solid gray rectangle,
> and it is visually  very disturbing to see it toggle between an arrow
> and a gray rectangle.  On linux with wx 2.5.3, the arrow button still
> looks like an arrow, but is gray to indicate "not enabled"
> 
> Does this feature work properly for anyone on windows?  Other
> WX/Windows users, please send me your wxpython version numbers and let
> me know if this is working for you so we can file a bug report to the
> wx list.  You can get your wxpython version by running your script
> with 
> 
>   > python myscript.py -dWXAgg --verbose-helpful
> 
> Thanks!
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

       Hello,

I tried to use one of my script and I obtain this error.
I tried the cvs (above for the version) and the matplotlib 0.81 and both 
have the problem.

It's just a typo in the file artist.py line 407.

return geto(o, *args, **kwargs)

must be replace by:

return getp(o, *args, **kwargs)

regards,

N.



Traceback (most recent call last):
  File "fig_faber_jackson3.py", line 248, in ?
    xticklabels = get(gca(), 'xticklabels')
  File "/usr/local/lib/python2.4/site-packages/matplotlib/artist.py", 
line 407, in get
    return geto(o, *args, **kwargs)
NameError: global name 'geto' is not defined


===================================================================
File: artist.py         Status: Up-to-date

   Working revision:    1.23
   Repository revision: 1.23    
/cvsroot/matplotlib/matplotlib/lib/matplotlib/artist.py,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

kei...@bt... wrote:

>I got these errors doing "python setup.py build" on my redhat 9 system using python 2.4.
>Keith
>
>/usr/local/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined
>In file included from /usr/include/c++/3.2/i386-redhat-linux/bits/os_defines.h:39,
>                 from /usr/include/c++/3.2/i386-redhat-linux/bits/c++config.h:34,
>                 from /usr/include/c++/3.2/iosfwd:44,
>                 from /usr/include/c++/3.2/ios:44,
>                 from /usr/include/c++/3.2/istream:44,
>                 from /usr/include/c++/3.2/sstream:44,
>                 from src/ft2font.cpp:1:
>/usr/include/features.h:131:1: warning: this is the location of the previous definition
>src/ft2font.cpp: In member function `Py::Object Glyph::get_path(FT_FaceRec_*
>   const&)':
>src/ft2font.cpp:111: `FT_CURVE_TAG_CUBIC' undeclared (first use this function)
>src/ft2font.cpp:111: (Each undeclared identifier is reported only once for each
>   function it appears in.)
>src/ft2font.cpp:114: `FT_CURVE_TAG_CONIC' undeclared (first use this function)
>src/ft2font.cpp:117: `FT_CURVE_TAG_ON' undeclared (first use this function)
>src/ft2font.cpp: In member function `Py::Object FT2Font::set_text(const
>   Py::Tuple&)':
>src/ft2font.cpp:719: `FT_KERNING_DEFAULT' undeclared (first use this function)
>src/ft2font.cpp: In function `void initft2font()':
>src/ft2font.cpp:1686: `FT_KERNING_UNFITTED' undeclared (first use this
>   function)
>src/ft2font.cpp:1687: `FT_KERNING_UNSCALED' undeclared (first use this
>   function)
>error: command '/usr/bin/gcc' failed with exit status 1
>  
>

Keith:  You are  freetype package is too old, you need 2.1.9 or newer.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

On 2005-04-09 11:59:54 GMT, John Hunter wrote:

> The Axes is the white space that contains the lines, rectangles, text
> etc.  The Figure is the whole canvas that contains the Axes.  The
> default Axes is created by Subplot(111) which leaves empty space at
> the left, bottom, top, right and bottom.  You can create your own Axes
> dimensions. with the "axes" command

>    http://matplotlib.sf.net/matplotlib.pylab.html#-axes

> Eg, to leave no room at right or top, use

>   ax = axes([0.1, 0.1, 0.9, 0.9])

Hi all,
well, I'm sorry to wake up an old thread, but what if there are subplots in 
the figure ? I tried to ask

  axes([0.1, 0.1, 0.9, 0.9])

before specifying my subplot()s, but it changed nothing.

How to reduce the margin of the whole figure when it has subplots ?

Cheers,
Nicolas