matplotlib-users Mailing List for matplotlib (Page 4)

Is there a way for the legend to be outside of the axis?  Perhaps
rendered separately.

=20

thanks,

S

Interesting message from the Boa-constructor mailing list....

Anyone would be interested in helping?

cheers

-------- Mensagem Original --------
Assunto: 	[Boa Constr] matplotlib plugin
Data: 	Tue, 9 Mar 2004 18:10:57 -0000
De: 	Ricardo Henriques <pax...@sa...>
Para: 	Boa Constructor <boa...@li...>



Ok... I´m going to check if I can make a boa plugin for the matplotlib 
WX backend.
If anyone would like to help =) it would be great..
 
Tks eveyone for the input about the plotting librarys and features.
 
Ricardo
 
 

There is a minor bug in the object_picker.py example. On the 2nd and
subsequent times a line is "picked", if the marker style had been
changed previously, the original marker choice "None" no longer appears
as a choice in the marker menu.  I.e. there is no way to turn off a
previously selected marker.

Below is a (one line) patch that fixes this.

	-Al   
-- 
Al Schapira <a.d...@wo...>

 
*** /usr/local/matplotlib-0.51/examples/object_picker.py       
2004-02-26 15:22:58.000000000 -0500
--- object_picker.py    2004-03-09 16:50:36.000000000 -0500
***************
*** 151,157 ****
          marker = line.get_marker()
          if marker is None: marker = 'None'
          styles = [marker]
!         for key in lineMarkers.keys():
              if key == marker: continue
              styles.append(key)
   
--- 151,157 ----
          marker = line.get_marker()
          if marker is None: marker = 'None'
          styles = [marker]
!         for key in keys:
              if key == marker: continue
              styles.append(key)

>>>>> "Trevor" == Trevor Blackwell <tl...@an...> writes:

    Trevor> In backend_gtk.py, it does some antialiased rendering by
    Trevor> direct manipulation of pixel values which is only correct
    Trevor> for 24-bit TrueColor X11 visuals. I'm running a 16-bit (5
    Trevor> red, 6 green, 5 blue) visual, so this produces visual
    Trevor> junk.

    Trevor> I think the right way to do it is with a Pixbuf, which
    Trevor> handles alpha rendering. The code is much simpler and
    Trevor> faster too. Here is a patch:

Nice!!  Where did you learn that trick?  pb.pixel_array is not
documented at
http://www.gnome.org/~james/pygtk-docs/class-gdkpixbuf.html.

This is great to know because I can use the same approach to port
image handling to gtk once I get that up and running.

FYI, your patch was line wrapped but it was simple enough to apply "by
eye".

JDH

In backend_gtk.py, it does some antialiased rendering by direct
manipulation of pixel values which is only correct for 24-bit TrueColor
X11 visuals. I'm running a 16-bit (5 red, 6 green, 5 blue) visual, so
this produces visual junk.

I think the right way to do it is with a Pixbuf, which handles alpha
rendering. The code is much simpler and faster too. Here is a patch:

(This is from matplotlib-0.51.)

--- backends/backend_gtk.py~     Wed Mar  3 09:31:39 2004
+++ backends/backend_gtk.py      Tue Mar  9 12:00:37 2004

@@ -350,47 +351,20 @@
         xox = int(x+ox)
         yoy = int(y+oy)
 
-
-
         imw = min(imw, self.width-xox)
         imh = min(imh, yoy)
-        #print imw, imh, xox, yoy, self.width, self.height
-        image = self.gdkDrawable.get_image(xox, self.height-yoy, imw,
imh)
-        #return
-
-
-        tr = int(rgb[0]*255) # text red
-        tg = int(rgb[1]*255) # text green
-        tb = int(rgb[2]*255) # text blue
-
-        ind =  indices(Xs.shape)
-        numRows, numCols = Xs.shape
-        ind.shape = 2, numRows*numCols
-        Xs.shape = numRows*numCols,
-        visible = nonzero(Xs>0)
-        Xs.shape = numRows,numCols
-        for thisInd in visible:
-            j,i = ind[:,thisInd]
-            if i >= imw: continue
-            if j >= imh: continue
-            pixel = image.get_pixel(i, j)
-            br = (pixel >> 16)  & 0xff  # background red
-            bg = (pixel >> 8 ) & 0xff
-            bb = (pixel >> 0)  & 0xff
-            #print br, bg, bb, Xs[j,i]
-
-            alpha = int((255-Xs[j,i])*255)
-
-            nr = (((br - tr) * alpha) + (tr << 16)) >> 16
-            ng = (((bg - tg) * alpha) + (tg << 16)) >> 16
-            nb = (((bb - tb) * alpha) + (tb << 16)) >> 16
-            newpixel = (nr<<16) + (ng<<8) + (nb)
-            
-            image.put_pixel(i, j, newpixel)
 
-        self.gdkDrawable.draw_image(gc.gdkGC, image, 0, 0,
-                                    xox, self.height-yoy, imw, imh)
+        pb=gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB,
+                          has_alpha=1, bits_per_sample=8, width=imw,
height=imh)
+        pbpix=pb.pixel_array
+        pbpix[:,:,3]=Xs
+        pbpix[:,:,0]=int(rgb[0]*255)
+        pbpix[:,:,1]=int(rgb[1]*255)
+        pbpix[:,:,2]=int(rgb[2]*255)
 
+        pb.render_to_drawable(self.gdkDrawable, gc.gdkGC, 0, 0, xox,
self.height-yoy, imw, imh,
+                              gdk.RGB_DITHER_NONE, 0, 0)
+            
         if 0:
             self.gdkDrawable.draw_rectangle(
                 gc.gdkGC, 0, xox,


-- 
Trevor Blackwell      tl...@an...       (650) 210-9272

>>>>> "Kuzminski," == Kuzminski, Stefan R <SKu...@fa...> writes:

    Stephan> The GD output looks good when printed, maybe I will
    Stephan> switch between the 2 ( Agg for display, GD for
    Stephan> printing ).  The Agg un-aliased lines don't come out
    Stephan> quite as well, they seem to render more of the pixels
    Stephan> for each point on the line.  Nice to have the
    Stephan> different backend options.

This has to do with how agg handles subpixel positioning - I've
emailed the agg list and gotten some advice but haven't come up with a
good system to make the lines appear the same thickness in the aliased
and antialiased cases.  I'm still working on it.

In the meantime, here is a little backend magic that will make it
easier for you to print to your backend of choice. This example
displays the image in the default GUI (GTKAgg for me) and prints
with GD.  

    from matplotlib.backends.backend_gd import FigureCanvasGD
    from matplotlib.matlab import *

    plot([1,2,3])

    manager = get_current_fig_manager()
    canvasgd = manager.canvas.switch_backends(FigureCanvasGD)
    canvasgd.print_figure('gdfig')
    show()

print_figure takes the same args as savefig.

gd has a pesky color allocation bug that I haven't figured out that
you may bump into.

JDH

The GD output looks good when printed, maybe I will switch between the 2
( Agg for display, GD for printing ).  The Agg un-aliased lines don't
come out quite as well, they seem to render more of the pixels for each
point on the line.  Nice to have the different backend options.

S   =20

-----Original Message-----
From: John Hunter [mailto:jdh...@ni...]=20
Sent: Monday, March 08, 2004 8:37 AM
To: Kuzminski, Stefan R
Cc: mat...@li...
Subject: Re: [Matplotlib-users] simple api question

>>>>> "Kuzminski," =3D=3D Kuzminski, Stefan R <SKu...@fa...>
writes:

    Kuzminski> Thanks, that worked for the line being plotted,
    Kuzminski> although the legend box and axis are still aliased.
    Kuzminski> Part of my requirements include supporting
    Kuzminski> presentation quality printing.  I would like to just
    Kuzminski> use Agg as GD has dependency issues and keeps popping
    Kuzminski> up other problems ( not to mention how great the Agg
    Kuzminski> output looks ).  But that great looking anti-aliasing
    Kuzminski> doesn't print well, so ideally there would be a
    Kuzminski> 'global' level flag that controls aliasing ( or not )
    Kuzminski> for everything drawn.  I know when the image is being
    Kuzminski> created for viewing or for printing and so can set the
    Kuzminski> flag accordingly.

I'll work on getting the rest of the objects to respect the
antialiased flag.  You can control antialiasing for all lines globally
with rcParams

  http://matplotlib.sourceforge.net/faq.html#CUSTOM


JDH

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@ci...> writes:

    Flavio> I cant install matplotlib because it cant find some files
    Flavio> in the Font tools tree.


Note if you just want wx, set all the BUILD_* flags in setup.py to 0
and distutils won't compile anything; wx doesn't depend on any of the
extension code.  If you do want to build the extensions from CVS, read
on.

CVS doesn't have a complete version of the FontTools* and ttfquery
that are needed to build the extensions.  An increasing number of
matplotlib backends need font-finding capabilities which FontTools and
ttfquery provide.  However, they are a pain to install and Paul
Barrett has been working on a replacement.  At one point I added them
to CVS since I was distributing them with matplotlib but thought twice
about it and tried to remove them.  However despite multiple attempts
I have not been able to get them out of CVS.  No in a nutshell there
is an incomplete version of FontTools and ttfquery in CVS, and I'm not
too inclined to add them since they will be purged in short order in
any case with the new fontfinder.

If you want to build from CVS, copy the agg, FontTools* and ttfquery
dirs/files from the 0.51 src distro into the CVS tree and build from
there.  This will all be cleared up soon.

JDH

errata of my last message:

I meant to say that:

these folders did not come with cvs update -d


Summarizing,


I cant install matplotlib because it cant find some files in the Font
tools tree.

hi, I am trying to install the latest CVS and I am getting the following
error message:


root@iprocc1-164 matplotlib]# python setup.py install
running install
running build
running build_py
package init file 'ttfquery/__init__.py' not found (or not a regular
file)
package init file 'FontTools/__init__.py' not found (or not a regular
file)
package init file 'FontTools/fontTools/__init__.py' not found (or not a
regular file)
package init file 'FontTools/fontTools/encodings/__init__.py' not found
(or not a regular file)
error: package directory 'FontTools/fontTools/misc' does not exist
[root@iprocc1-164 matplotlib]# python setup.py install
running install
running build
running build_py
package init file 'ttfquery/__init__.py' not found (or not a regular
file)
package init file 'FontTools/__init__.py' not found (or not a regular
file)
package init file 'FontTools/fontTools/__init__.py' not found (or not a
regular file)
package init file 'FontTools/fontTools/encodings/__init__.py' not found
(or not a regular file)
error: package directory 'FontTools/fontTools/misc' does not exist

these folder did come with cvs update -d

what wrong here?

thanks for any help...

FLavio

HI everybody,

I dont know if any of you is aware of the boa-constructor python IDE and
wx gui builder.

I use it and subscribe to its mailing list. Recently, there was this
discussion about having some scientific plotting controls added to Boa.
I include below, a message from Boa's main developer, Ryaan Booysen,
where he gives some pointers to anyone that might be interested in
adding plotting controls to Boa. They are talking about Chaco, but as
far as I know, Chaco development is stalled and Matplotlib is far
superior (IMHO).

I believe that if anyone is interested in doing that should contact
Ryaan. He is a very nice guy. I also believe that it would greatly
improve the visibility of matplotlib since Boa has a very large user
base.

Well, its just an idea.

have fun

Flavio



-----Forwarded Message-----

From: Riaan Booysen <riaan@e.co.za>
To: Ricardo Henriques <pax...@sa...>
Cc: boa...@li... <boa...@li...>
Subject: Re: [Boa Constr] Fw: Any Chaco plugins?
Date: Tue, 09 Mar 2004 13:33:00 +0200

Hi Ricardo,

Ricardo Henriques wrote:
> Hi...
> I sucessfully used Boa to help me build scientific applications. I normally
> use wxPyPlot to plot graphics witch has a plug-in for Boa, it is quite
> alright, but sometimes I nead a plotting library with more features like
> Chaco found at www.scipy.org . Anyone knows any plug-in for this plotting
> library or any other than wxPyPlot?
> Where can I get some information about how to build a plug-in for Boa? 
> Tks...

You may look at the examples for adding a control in
Plug-ins/UserCompanions.py

I suggest you first try to use the Custom Classes feature to
use a Chaco Plot window in the Designer.
See Docs/boa/apphelp/MixingSource.html
This might be a simpler option.

Cheers,
Riaan.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Boa-constructor-users mailing list
Boa...@li...
https://lists.sourceforge.net/lists/listinfo/boa-constructor-users

>>>>> "Vincent" == Vincent BOYER <bo...@cl...> writes:
    Vincent> Is there a way to do that in Matplotlib?  Does the Matlab
    Vincent> command "hold" have a equivalent in Matplotlib? I didn't
    Vincent> find it, and if it exists, then I could plot the lines of
    Vincent> the matrix Y one by one.

Hold is on by default.  So you can do


for y in Y:
    plot(x,y)

To clear the axes between plot commands, use gca.

Hope this helps,
JDH

Hi.

I'm trying to plot a matrice against a vector using Matplotlib.
Something like we can do with Matlab :

plot(x,Y)

where
    x is an Numeric.array of shape (n,)
    Yis an Numeric.array of shape (m,n)

Is there a way to do that in Matplotlib?
Does the Matlab command "hold" have a equivalent in Matplotlib? I didn't 
find it, and if it exists, then I could plot the lines of the matrix Y 
one by one.

Thank you for any information.

Vincent

It seems to me, from the user's point of view, that the DPI is a rendering
option, not a plotting option. I should be able to take the same plot:

p = plot(sin(x))

and render it to screen 

show(p, dpi=96, size=(8, 6))

OR

show(p, pixelsize=(768, 576))

or render it for printing:

savefig('p.png', dpi=300, size=(6, 4))

OR

savefig('p.png', pixelsize=(1800, 1200))

OR

savefig('p.eps', size=(6, 4))

I think people are going to want different DPI settings for screen vs.  
printing. So perhaps dpi should be an option to show() and savefig()
rather than to plot?

And rather than having different DPI defaults for each backend, I would 
have thought it better to have two global default DPI settings, one for 
the screen and one for the printer. You would also want two default plot 
sizes in inches.

In a sane world you wouldn't need to set the DPI for the screen, you could
trust X or Windows to provide it, but in practice what X says isn't always
useful.

You might even consider adding a print() command that renders a plot with 
the default printing settings to a file (or even straight to the 
printer?). Perhaps savefig() should use the default printing settings when 
exporting an .eps file? (Although the DPI is ignored the plot size is 
still relevant.)

I hope you find these ponderings useful. I am still a bit ignorant about
aspects of matplotlib so I'll hope you'll excuse me for that.

Cheers,
Matthew.

On Mon, 8 Mar 2004, John Hunter wrote:

> None of this matters, of course, for PS, which is resolution
> independent.
> 
> dpi is not really suitably named because of this additional parameter
> PIXELS_PER_INCH.  dpi is really a resolution parameter.  When you
> increase dpi, the relative sizes of everything in your image should
> increase proportionately (line widths, text sizes, etc) but you have
> more pixels of resolution.  When you increase figure size for a give
> dpi, everything should appear smaller because the physical size of the
> objects in your canvas haven't changed, but your canvas has increased.
> 
> I'm open to suggestions on how to make this better.
> 
> JDH

>>>>> "Al" == Al Schapira <a.d...@wo...> writes:

    Al> In order to get the size of the overall plot window to
    Al> anywhere near full screen, I've had to use something like

    Al> 	figure(1, figsize=(18,12), dpi=72) or figure(1,
    Al> figsize=(9,6), dpi=144)

    Al> Both produce the same overall size plot window (11.25" wide by
    Al> 8" tall), but in the latter case, the text size is much larger
    Al> than in the latter case. Likewise the linewidths.

    Al> Can you please explain the interaction among the dpi value,
    Al> the font sizes displayed, and the overall plot size.

Hi Al, 

This is a complicated issue and I don't have a full answer for you.
The problem is compounded by the fact that I am trying to make the DPI
parameter produce figures that look the same across the backends, and
different backends have often have an additional parameter that makes
assumptions about the number of pixels per inch on your display - eg
gd assumes 96, and these are not under my control.  

The total figure width in pixels is figure width in inches * dpi;
ditto for height.  If you set dpi to your device PIXELS_PER_INCH, the
width should be correct if you measure it on the screen with a ruler.
You will probably need to set PIXELS_PER_INCH for the backend you are
using to be correct for your display.  This is a parameter the
respective backend files, eg, in matplotlib/backends/backend_gtk.py.
For backend_agg, you will have to change it both in
src/_backend_agg.cpp and matplotlib/backends/backend_agg.py.  This is
something I would like to rationalize and perhaps move to the rc file.
I suggest setting it to your display width / pixels width, eg, 116 in
your example.  Then

  figure( (8,6), dpi=116)

should produce a an 8 inch by 6 inch figure.  Let me know.  Then
default dpi can be set in the rc file.

None of this matters, of course, for PS, which is resolution
independent.

dpi is not really suitably named because of this additional parameter
PIXELS_PER_INCH.  dpi is really a resolution parameter.  When you
increase dpi, the relative sizes of everything in your image should
increase proportionately (line widths, text sizes, etc) but you have
more pixels of resolution.  When you increase figure size for a give
dpi, everything should appear smaller because the physical size of the
objects in your canvas haven't changed, but your canvas has increased.

I'm open to suggestions on how to make this better.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> 2) Is it a bug that the polygon is not filled

Yes, none of the rest of the drawing interface uses Polygon so I
hadn't noticed it.  In patches.py, replace line 330 with 

        renderer.draw_polygon(gc, rgbFace, vertices)

Below is your (modified) original script, with comments that answer
your questions.  With the patch above and some changes I made, it now
works (cool).  It would be nice to figure out how to properly include
this in the regular API.

JDH

from matplotlib.matlab import *
from matplotlib.patches import Rectangle, Polygon

def filly(x,y1,y2,**kwargs):
     ax = gca()
     xy = []
     for xi, yi in zip(x,y1):
         xy.append( (xi,yi) )
     for xi, yi in zip(x[::-1],y2[::-1]):
         xy.append( (xi,yi) )
     xy.append( xy[0] )


     # see
     # http://matplotlib.sourceforge.net/matplotlib.transforms.html
     # for information on the new transform system.  You can place
     # objects in a variety of coord systems, most freqeuntly data or
     # axes.  data are the old-style coords you are used to.  axes
     # coords are normalized on a 0-1 scale.  The xaxis and yaxis
     # instances store default transforms so you can easily create new
     # objects in either coord system.  ax.xaxis.transData transforms
     # data units to display units for the xaxis.  ax.xaxis.transAxis
     # transforms axis units to display units.  You have done it right
     # here.
     polygon = Polygon(
         ax.dpi, ax.bbox,
         xy,
         transx = ax.xaxis.transData, # what does this do?
         transy = ax.yaxis.transData, # and this??
         **kwargs)

     ax.add_patch(polygon)
     return polygon

figure(1)
t = arange(0.0, 1.0, 0.01)
s_mean = 0.5*sin(2*2*pi*t)
s_lo = s_mean-0.1
s_hi = s_mean+0.1
#plot(t,s_mean,'k')
filly(t,s_lo,s_hi,fill=1,facecolor='g')

# I haven't decided yet on how to handle autoscaling with patches
# since there is no efficient easy way to get the patch's extent in
# data coords.  Instead, I update the datalim manually in plot
# commands that use pataches
gca().xaxis.datalim.update((min(t), max(t)))
gca().yaxis.datalim.update((min(s_lo), max(s_hi)))

# now this should work since the data lim are updated
gca().xaxis.autoscale_view() 
gca().yaxis.autoscale_view()
#savefig('filly')
show()

In order to get the size of the overall plot window to anywhere near
full screen, I've had to use something like 

	figure(1, figsize=(18,12), dpi=72)
or	figure(1, figsize=(9,6),   dpi=144)

Both produce the same overall size plot window (11.25" wide by 8" tall),
but in the latter case, the text size is much larger than in the latter
case. Likewise the linewidths.

Can you please explain the interaction among the dpi value, the font
sizes displayed, and the overall plot size.

Note: If I omit the dpi parameter, the plot window remains at its
default (approx 4" x 3") size.  The only way I've gotten the window size
to change at all is by adding the dpi parameter to the fiigure() call,
hence the question.

FYI, this is under RH linux 9, with XFree86 4.3.0-2.

The display is a 15" diagonal (12" horizontal, 9" vertical) Dell laptop
with 1400x1050 NVIDIA GeForce 4 (generic) graphics. Naively, this looks
like the H-res is 1400/12" = 116.66 dpi and the V-res is 1050/9" =
116.66 dpi also.

Should I set dpi to the resolution of my display (117) or to the
resolution of the X fonts (75 or 100)?

Thanks,
-- 
Al Schapira <a.d...@wo...>

>>>>> "Kuzminski," == Kuzminski, Stefan R <SKu...@fa...> writes:

    Kuzminski> Thanks, that worked for the line being plotted,
    Kuzminski> although the legend box and axis are still aliased.
    Kuzminski> Part of my requirements include supporting
    Kuzminski> presentation quality printing.  I would like to just
    Kuzminski> use Agg as GD has dependency issues and keeps popping
    Kuzminski> up other problems ( not to mention how great the Agg
    Kuzminski> output looks ).  But that great looking anti-aliasing
    Kuzminski> doesn't print well, so ideally there would be a
    Kuzminski> 'global' level flag that controls aliasing ( or not )
    Kuzminski> for everything drawn.  I know when the image is being
    Kuzminski> created for viewing or for printing and so can set the
    Kuzminski> flag accordingly.

I'll work on getting the rest of the objects to respect the
antialiased flag.  You can control antialiasing for all lines globally
with rcParams

  http://matplotlib.sourceforge.net/faq.html#CUSTOM


JDH

Thanks, that worked for the line being plotted, although the legend box
and axis are still aliased.  Part of my requirements include supporting
presentation quality printing.  I would like to just use Agg as GD has
dependency issues and keeps popping up other problems ( not to mention
how great the Agg output looks ).  But that great looking anti-aliasing
doesn't print well, so ideally there would be a 'global' level flag that
controls aliasing ( or not ) for everything drawn.  I know when the
image is being created for viewing or for printing and so can set the
flag accordingly.

S

-----Original Message-----
From: John Hunter [mailto:jdh...@ni...]=20
Sent: Monday, March 08, 2004 8:16 AM
To: Kuzminski, Stefan R
Cc: mat...@li...
Subject: Re: [Matplotlib-users] simple api question

>>>>> "Kuzminski," =3D=3D Kuzminski, Stefan R <SKu...@fa...>
writes:

    Kuzminski,> I got the .51 release, looks great.  I need to
    Kuzminski,> set_antialiased() on the Renderer, but I'm not sure
    Kuzminski,> how to get the renderer object correctly.  If I call
    Kuzminski,> gca() I get the SubPlot, but the renderer member is
    Kuzminski,> None.  Any advice would be appreciated.

There is no way to set antialiased on the renderer itself, just on the
individual objects (lines etc).
 =20
  plot([1,2,3], antialiased=3DFalse)

or=20

  lines =3D plot(x1,y1,x2,y2)
  set(lines, 'antialiased', False)

or set lines.antialiased in matplotlibrc to the default you want.

Unfortunately, agg does not yet respect antialiased =3D=3D False for all
primitives, currently only lines.

See also

  http://matplotlib.sourceforge.net/faq.html#MATPLOTLIBRC
  http://matplotlib.sourceforge.net/faq.html#CUSTOM

Can you tell me what you're trying to do?

JDH

>>>>> "Kuzminski," == Kuzminski, Stefan R <SKu...@fa...> writes:

    Kuzminski,> I got the .51 release, looks great.  I need to
    Kuzminski,> set_antialiased() on the Renderer, but I'm not sure
    Kuzminski,> how to get the renderer object correctly.  If I call
    Kuzminski,> gca() I get the SubPlot, but the renderer member is
    Kuzminski,> None.  Any advice would be appreciated.

There is no way to set antialiased on the renderer itself, just on the
individual objects (lines etc).
  
  plot([1,2,3], antialiased=False)

or 

  lines = plot(x1,y1,x2,y2)
  set(lines, 'antialiased', False)

or set lines.antialiased in matplotlibrc to the default you want.

Unfortunately, agg does not yet respect antialiased == False for all
primitives, currently only lines.

See also

  http://matplotlib.sourceforge.net/faq.html#MATPLOTLIBRC
  http://matplotlib.sourceforge.net/faq.html#CUSTOM

Can you tell me what you're trying to do?

JDH

>>>>> "Al" == Al Schapira <a.d...@wo...> writes:

    Al> [ I posted this directly to
    Al> mat...@li... previously, but I
    Al> didn't see it show up there. Sorry if you got this
    Al> before. --Al]

I have seen it, just haven't had a chance to look at it yet.  It's on
the list...

JDH

I got the .51 release, looks great.  I need to set_antialiased() on the
Renderer, but I'm not sure how to get the renderer object correctly.  If
I call gca() I get the SubPlot, but the renderer member is None.  Any
advice would be appreciated.

=20

thanks,

S

>>>>> "John" == John Wohlbier <jd...@go...> writes:

    John> Another clue, when I try another example with wx I get:
    John> wohlbier@gyrotwystron examples $ python dynamic_demo_wx.py
    John> Traceback (most recent call last): File
    John> "dynamic_demo_wx.py", line 34, in ?  from
    John> matplotlib.backends import Figure, Toolbar, FigureManager
    John> ImportError: cannot import name Figure wohlbier@gyrotwystron
    John> examples $

    John> Does this mean anything?

Well, it appears dynamic_demo_wx has not been updated to the latest
API.  Ignore this one for now.


What happens when you do

  > python2.3 simple_plot.py -dWX

Does it help to do

  > python2.3 embedding_in_wx.py -dWX

It shouldn't because you have selected wx as your default backend in
matplotlibrc, but I find your problem a little mysterious so I'm
grasping here.

Please send me the embedding_in_wx.py you are trying to run as an
attachement so I can see if I can replicate it on my system.

JDH

[ I posted this directly to mat...@li... previously,
but I didn't see it show up there. Sorry if you got this before. --Al]

I found that multi-line ticklabels work fine in normal (hortizontal) 
mode.  However, after a  "set(t, 'rotation', 'vertical')"  the plot fails 
as shown below. The plot window pops up, then disappears.
System is RH linux 9, matplotlib 0.51, pygtk 2.0.0,

Are multi-line labels supported?  In vertical mode too?

Thanks for your help.

	-Al Schapira, a.d...@wo...


### This is based upon the "vertical_ticklabels.py" in /examples.

[ads@ADS1 py]$ cat vertical_ticklabels.py
from matplotlib.matlab import *

plot([1,2,3,4], [1,4,9,16])
set(gca(), 'xticks', [1,2,3,4])

t = set(gca(), 'xticklabels', ['Frogs\nOKAY 1', 'Hogs\nFine 2', 
Bogs\nGOOD 3', 'Slogs'])

set(t, 'rotation', 'vertical')  # UNCOMMENT THIS to make the above fail

show()

[ads@ADS1 py]$ python vertical_ticklabels.py

The program 'vertical_ticklabels.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
   (Details: serial 1083 error_code 8 request_code 73 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() 
function.)

[ I posted this directly to mat...@li... previously,
but I didn't see it show up there. Sorry if you got this before. --Al]

I am generating a plot with multi-line ticklabels.
Although the plot displays normally, clicking on the SAVE icon fails
(after selecting a target file name ending with .ps).

I tracked this down as far as afm.get_str_bbox(), line 307 in afm.py

It appears to me that the '\n' character in my multi-line label is
causing the following error:

   File "/usr/local/lib/python2.3/site-packages/matplotlib/afm.py", line
307, in get_str_bbox
    wx, name, bbox = self._metrics[ord(c)]
KeyError: 10

Note that '\n' == 10.  I confirmed the failure with a tiny example:
Run the following and click on the SAVE icon, enter a file name ending
in .ps, and observe the failure.

################################
from matplotlib.matlab import *

plot([1,2,3,4], [1,4,9,16])
set(gca(), 'xticks', [1,2,3,4])

t = set(gca(), 'xticklabels', ['Frogs\nOKAY 1', 'Hogs\nFine 2',
'Bogs\nGOOD 3', 'Slogs'])

show()
################################

Although I realize that computing the bounding box of a multi-line text
is a bit more complex, I would really like to see this supported.

Also, I don't know in how many other places the embedded '\n' will cause
problems.

Thanks.

-- 
Al Schapira <a.d...@wo...>