matplotlib-users Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     Fernando> Hi all, I wonder how I can get, in an easy way, the
>     Fernando> number of a figure returned by a call to figure(None).
>     Fernando> The nasty way is:
> 
>     Fernando>          allnums = [f.num for f in
>     Fernando> _pylab_helpers.Gcf.get_all_fig_managers()] if allnums:
>     Fernando> num = max(allnums) + 1 else: num = 1
> 
>     Fernando> but this seems horrible for everyday, user-level code.
>     Fernando> What I want to do is simply be able to make a call to:
> 
>     Fernando> ff=figure()
> 
>     Fernando> and then later make a series of plots which go to that
>     Fernando> figure:
> 
>     Fernando> myplotfunc(fignum=ff.num) myplotfunc2(fignum=ff.num) ...
> 
> What if we just attach the num attribute in the pylab figure function
> 
>     figManager.canvas.figure.num = num
>     return figManager.canvas.figure

That's pretty much what I think would be the simplest solution, and I'd be 
happy with it.

It would be nice if this little change made it into .73, along with removing 
this section from figure:

     if num==0:
         error_msg('Figure number can not be 0.\n' + \
                   'Hey, give me a break, this is matlab(TM) compatability')
         return


Best,

f

What's new in matplotlib 0.73

new contour functionality

  Filled contours (polygons) with contourf and clabel . See
  examples/contour_demo.py, examples/contourf_demo.py,
  examples/contour_image.py and the screenshot at
  http://matplotlib.sf.net/screenshots.html#pcolor_demo. Thanks Nadia
  and Eric for lots of hard work. This code is not perfect, so please
  let us know if you find bugs or problems.

native font support back in PS

  Added new rc param param ps.useafm so ps backend can use native
  fonts; this currently breaks PS mathtext but makes for smaller files

colorbar now a figure method

  Refactored colorbar code out of pylab into Figure API for API
  developers. matplotlib.pylab colorbar is now a thin wrapper to this
  function.

minor enhancements and bug-fixes

  Experimental support for GTK w/o double buffering, added double
  buffering to gtkagg, exposed some core agg functionality in
  matplotlib.agg, upgraded wrapper generator to CXX 5.3.1, added a
  custom pixel transfer function for GTK which works for Numeric and
  numarray, added patch for problem with Japanse fonts in windows
  registry, fixed ticks for horizontal colorbars, fixed labelsep
  legend bug

Downloads at http://matplotlib.sf.net

JDH

>>>>> "Russell" == Russell E Owen <ro...@ce...> writes:

    Russell> Thanks. That was helpful -- though also a bit confusing,
    Russell> in that I'm using the TkAgg back end and calling
    Russell> pylab.draw() doesn't update anything visible on my
    Russell> FigureCanvasAgg object. (As an aside, calling show() on
    Russell> my FigureCanvasAgg object seems to work -- the code
    Russell> originally did that when I got it -- but the manual and
    Russell> FAQ clearly point to using draw instead).

I looked back over the code you posted previously and see that you are
using the API, eg making your own tk canvases.  In this case you
should not import pylab at all.  Do everything from the class API.
Call canvas.draw() rather than pylab.draw().

You can still use matplotlib.numerix to get all the Numeric/numarray
symbols, but the pylab interface doesn't mix well with the API
interface because pylab tries to manage figure creation and
destruction for you.

Instead of

  f = figure(figsize=(3,3))  # this is a pylab call
  sp = f.add_subplot(111)
  canvas = FigureCanvasTkAgg(f, master=root)

do 

from matplotlib.figure import Figure

  f = Figure(figsize=(3,3))  # this is an API call
  sp = f.add_subplot(111)
  canvas = FigureCanvasTkAgg(f, master=root)

See also examples/agg_oo.py and this post for a tutorial introduction
the matplotlib API

  http://sourceforge.net/mailarchive/message.php?msg_id=11033442

Hope this helps,
JDH

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

    Fernando> Hi all, I wonder how I can get, in an easy way, the
    Fernando> number of a figure returned by a call to figure(None).
    Fernando> The nasty way is:

    Fernando>          allnums = [f.num for f in
    Fernando> _pylab_helpers.Gcf.get_all_fig_managers()] if allnums:
    Fernando> num = max(allnums) + 1 else: num = 1

    Fernando> but this seems horrible for everyday, user-level code.
    Fernando> What I want to do is simply be able to make a call to:

    Fernando> ff=figure()

    Fernando> and then later make a series of plots which go to that
    Fernando> figure:

    Fernando> myplotfunc(fignum=ff.num) myplotfunc2(fignum=ff.num) ...

What if we just attach the num attribute in the pylab figure function

    figManager.canvas.figure.num = num
    return figManager.canvas.figure

Hi all,

I wonder how I can get, in an easy way, the number of a figure returned by a 
call to figure(None).  The nasty way is:

         allnums = [f.num for f in _pylab_helpers.Gcf.get_all_fig_managers()]
         if allnums:
             num = max(allnums) + 1
         else:
             num = 1

but this seems horrible for everyday, user-level code.  What I want to do is 
simply be able to make a call to:

ff=figure()

and then later make a series of plots which go to that figure:

myplotfunc(fignum=ff.num)
myplotfunc2(fignum=ff.num)
...


I need to overlay a set of plots on the same figures, and I don't want to 
manage manually the figure numbering.  I'm comparing results across runs of a 
script, so the automatic figure(None) number increase is perfect.  But I need 
a way to get a hold of those numbers somehow, and I don't see how.  I looked 
at the attributes in the returned figure object, and I couldn't find the 
number anywhere (I think it's hidden higher up in the figure manager object).

An alternate (perhaps more 'pythonic'?) solution would be to allow figure() to 
take figure objects (not just numbers) as arguments.  In this case, it would 
simply be a matter of saying:

ff=figure()

and then later make a series of plots which go to that figure:

myplotfunc(fig=ff)
myplotfunc2(fig=ff)

At any rate, either an integer-based or an object-based solution would work 
for me, so I'll be grateful for any pointers.

best,

f

In article <m3r...@pe...>,
 John Hunter 
 <jdh...@ac...> wrote:

> >>>>> "Perry" == Perry Greenfield 
> >>>>> <pe...@st...> writes:
> 
>     Perry> My guess is that the hold mode is true (that's the
>     Perry> default). I think this means that every time you call
>     Perry> .pcolor that you are just appending another one to the
>     Perry> axes. You should either change the default hold mode or
>     Perry> call the .clear() method of the axes object before calling
>     Perry> the .pcolor method. If you don't do that it is rendering n
>     Perry> previous versions and the time it takes grows linearly.
> 
> Good catch Perry.  You need
> 
> sp.hold(False)

Thank you both very much. That did the trick. I put a hold on the figure 
and then a hold(False) on the one axis for which I wanted it and all 
works well now.

>     >> P.S. At risk of distracting from the main problem: I am not
>     >> entirely sure I'm commanding a redraw in the correct
>     >> fashion. I'm fuzzy on the difference between show and
>     >> plot. Using canvas.show() and canvas.plot() both seem to
>     >> work. Just calling plot() doesn't. Any hints on this or
>     >> pointers to documentation would be appreciated.
> 
> See  http://matplotlib.sourceforge.net/faq.html#SHOW

Thanks. That was helpful -- though also a bit confusing, in that I'm 
using the TkAgg back end and calling pylab.draw() doesn't update 
anything visible on my FigureCanvasAgg object. (As an aside, calling 
show() on my FigureCanvasAgg object seems to work -- the code originally 
did that when I got it -- but the manual and FAQ clearly point to using 
draw instead).

>     >> Also, is pcolor documented anywhere?
>...
> All the class docs can be found at
> http://matplotlib.sourceforge.net/classdocs.html.  In particular,

That's what I was really missing. Thanks! Now that I know about it, I'm 
not sure how I missed it the first time. Oh well...

-- Russell

>>>>> "Natsu" == Natsu  <nat...@ya...> writes:

    Natsu> Hi, Thanks to MASUDA-san's advice, I could find the
    Natsu> problematic TTF font.

    Natsu> Please see attached font JRLM00M.TTF

OK, I can replicate the bug on windows and linux -- thanks for the
test file.  Even though I've found where the bug is occurring -- the
call to 

  setattr("family_name",     Py::String(face->family_name);

in ft2font.cpp, the fix is not immediately obvious, so we'll continue
to work on it and I'll keep you posted.  In the interim, hopefully you
can remove the troublesome files from your font path and still use
matplotlib.

JDH

Just a reminder that there will be a matplotlib sprint on Monday the
21st before PyCon.  If you are in the DC area and what to hack on
matplotlib, please come out!

  http://www.python.org/moin/MatplotlibSprint

Hope to see you there!
JDH

>>>>> "Yasushi" == Yasushi MASUDA <ym...@et...> writes:

    Yasushi> Hello, This problem seems to caused by (unhandled)
    Yasushi> ft2font.pyd crash for some kind of third-party TTF fonts.

I will try and send you a debug build today so you can identify where
the problem font is.  Also, if you send me a problem ttf font file and
I can replicate the problem on my system, I can probably diagnose it
and fix it myself, which would be more efficient.  Thanks for working
on this.

JDH

On Fri, 2005-03-18 at 05:02, Jason Hoogland wrote:
> Second question: I can't install Matplotlib and maybe someone will have seen 
> the symptom before or have some bright ideas to help me figure it out.  I'm 
> running SuSE 9.1, python 2.3.3, and seem to have Tcl/Tk/Tkinter installed OK.  

> I set BUILD_GTKAGG = 0 in setup.py.  In an xterm as root I ran this and the 
> output follows
> 
> \start
> 
> # python setup.py build
> Xlib: connection to ":0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> Using default library and include directories for Tcl and Tk because a
> Tk window failed to open.  You may need to define DISPLAY for Tk to work
> so that setup can determine where your libraries are located.
> running build
> running build_py
> creating build
> creating build/lib.linux-i686-2.3
> copying lib/pylab.py -> build/lib.linux-i686-2.3
> creating build/lib.linux-i686-2.3/matplotlib
> copying lib/matplotlib/patches.py -> build/lib.linux-i686-2.3/matplotlib
> copying lib/matplotlib/_image.py -> build/lib.linux-i686-2.3/matplotlib
> 
> ... etc copying a bunch of files into the build directory

[mostly snipped]

> g++ -pthread -shared build/temp.linux-i686-2.3/src/_tkagg.o -L/usr/local/lib 
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -ltk 
> -ltcl -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o 
> build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so
> /linux1/usr/bin/../lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: 
> cannot find -ltk
> collect2: ld returned 1 exit status
> error: command 'g++' failed with exit status 1
> 
> \end
> 
> I'm figuring the "Tk window open failed" bit at the start is just because it 
> seems to take a few seconds for Tk windows to appear on my system, and its 
> not coded to wait.  

That "Tk window open failed" problem looks to me like it may be *the*
problem.   matplotlib opens a Tk window to help figure out where Tk is; 
the fallback isn't working.  In your case I think the Tk window failed 
because "root" is trying to open a window on a display owned by your
non-priviledged account.   Having the system say "no" to root about
anything is really counter intuitive to me,  but I've experienced it
myself and it's discussed some here:

http://lists.debian.org/debian-user/1998/09/msg00113.html

The article suggests that if you do

% xhost +localhost

in your non-priviledged account before trying to build as root,  X will
allow the Tk window open.

> So assuming that's not fatal, it seems the problem boils 
> down to "cannot find -ltk".  I have searched for a few hours on google to no 
> avail.  The only things I can suspect are maybe:
> 
> - I might be missing some installed components for development stuff in Tcl or 
> g++?

Maybe.  On my RHEL3 system,  I have tk-devel-8.3.5-92.2 installed.

Hope this helps,
Todd

Hi,

I have two questions, I'll ask the simple one first.  I migrated from Matlab 
to Octave which uses gnuplot and thus provides 3D plotting capability, which 
is adequate.  Matplotlib is 2D, are there any good 3D plotters out there for 
python?

Second question: I can't install Matplotlib and maybe someone will have seen 
the symptom before or have some bright ideas to help me figure it out.  I'm 
running SuSE 9.1, python 2.3.3, and seem to have Tcl/Tk/Tkinter installed OK.  
For example:

#!/usr/bin/env python

from Tkinter import *
root = Tk()
w = Label(root, text="Hello, world!")
w.pack()
root.mainloop()

does the right thing by bringing up a window with the text.

$PYTHONHOME = /usr

I set BUILD_GTKAGG = 0 in setup.py.  In an xterm as root I ran this and the 
output follows

\start

# python setup.py build
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Using default library and include directories for Tcl and Tk because a
Tk window failed to open.  You may need to define DISPLAY for Tk to work
so that setup can determine where your libraries are located.
running build
running build_py
creating build
creating build/lib.linux-i686-2.3
copying lib/pylab.py -> build/lib.linux-i686-2.3
creating build/lib.linux-i686-2.3/matplotlib
copying lib/matplotlib/patches.py -> build/lib.linux-i686-2.3/matplotlib
copying lib/matplotlib/_image.py -> build/lib.linux-i686-2.3/matplotlib

... etc copying a bunch of files into the build directory

copying lib/pytz/zoneinfo/Africa/Tripoli.py -> 
build/lib.linux-i686-2.3/pytz/zoneinfo/Africa
copying lib/pytz/zoneinfo/Africa/Banjul.py -> 
build/lib.linux-i686-2.3/pytz/zoneinfo/Africa
running build_ext
building 'matplotlib._nc_transforms' extension
creating build/temp.linux-i686-2.3
creating build/temp.linux-i686-2.3/src
creating build/temp.linux-i686-2.3/CXX
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/IndirectPythonInterface.cxx 
-o build/temp.linux-i686-2.3/CXX/IndirectPythonInterface.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxxsupport.cxx -o 
build/temp.linux-i686-2.3/CXX/cxxsupport.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c src/_nc_transforms.cpp -o 
build/temp.linux-i686-2.3/src/_nc_transforms.o -DNUMERIC=1
In file included from /usr/include/python2.3/Python.h:8,
                 from CXX/Objects.hxx:9,
                 from CXX/Extensions.hxx:18,
                 from src/_transforms.h:12,
                 from src/_nc_transforms.cpp:2:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/g++/i586-suse-linux/bits/os_defines.h:39,
                 from /usr/include/g++/i586-suse-linux/bits/c++config.h:35,
                 from /usr/include/g++/functional:53,
                 from src/_nc_transforms.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous 
definition
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxxextensions.c -o 
build/temp.linux-i686-2.3/CXX/cxxextensions.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c src/mplutils.cpp -o 
build/temp.linux-i686-2.3/src/mplutils.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxx_extensions.cxx -o 
build/temp.linux-i686-2.3/CXX/cxx_extensions.o -DNUMERIC=1
g++ -pthread -shared build/temp.linux-i686-2.3/src/_nc_transforms.o 
build/temp.linux-i686-2.3/src/mplutils.o 
build/temp.linux-i686-2.3/CXX/cxx_extensions.o 
build/temp.linux-i686-2.3/CXX/cxxsupport.o 
build/temp.linux-i686-2.3/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.3/CXX/cxxextensions.o -lstdc++ -lm -o 
build/lib.linux-i686-2.3/matplotlib/_nc_transforms.so
building 'matplotlib.backends._tkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/include -Isrc -Iagg22/include -I. -I/usr/local/include -I/usr/include 
-I/usr/local/include/freetype2 -I/usr/local/include/freetype2 
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -Isrc/freetype2 
-Iagg22/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 
-I/usr/include/freetype2 -I/usr/include/python2.3 -c src/_tkagg.cpp -o 
build/temp.linux-i686-2.3/src/_tkagg.o
g++ -pthread -shared build/temp.linux-i686-2.3/src/_tkagg.o -L/usr/local/lib 
-L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -ltk 
-ltcl -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o 
build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so
/linux1/usr/bin/../lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: 
cannot find -ltk
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1

\end

I'm figuring the "Tk window open failed" bit at the start is just because it 
seems to take a few seconds for Tk windows to appear on my system, and its 
not coded to wait.  So assuming that's not fatal, it seems the problem boils 
down to "cannot find -ltk".  I have searched for a few hours on google to no 
avail.  The only things I can suspect are maybe:

- I might be missing some installed components for development stuff in Tcl or 
g++?
- Maybe need to have some environment variables set (e.g. for Tk?)
- Have some sort of path mismatch where it's looking for something that is 
somewhere else?

I've compiled a few things successfully on this set up now and not come across 
this one, any thoughts appreciated.

Cheers
Jason

Hello,

This problem seems to caused by (unhandled) ft2font.pyd crash for some 
kind of third-party TTF fonts.

In font_manager.py, createFontDict:

try:
  font = ft2font.FT2Font(str(fpath))   # <---- HERE
except RuntimeError:
  verbose.report_error("Could not open font file %s"%fpath)
  continue

For any 'clean' Japanese WinXP box having only MS-bundled TTFfonts,
matplotlib 0.72.1 runs fine, but with some third-party fonts 
are problematic even though they seem to have no problem with other 
Windows applications. In my case, two Japanese fonts were wrong.
(I don't think this is Japanese-font specific problem, because I have 
many Japanese fonts in my C:/WINDOWS/Fonts directory.)

I'm now looking into ft2pyd sources to find exact cause, but it will 
take a while (I'm not expert in font handling). Instead, you may 
find fonts causing problem with following script:
---------------
import os
from matplotlib import rcParams
from matplotlib.ft2font import FT2Font
from matplotlib.font_manager import findSystemFonts

paths = [rcParams['datapath']]
if os.environ.has_key('TTFPATH'):
    ttfpath = os.environ['TTFPATH']
    if ttfpath.find(';') >= 0: #win32 style
        paths.extend(ttfpath.split(';'))
    else:
        paths.append(ttfpath)

ttffiles = findSystemFonts(paths) + findSystemFonts()

for fpath in ttffiles:
    print "probing %s" %(str(fpath))
    font = FT2Font(str(fpath))
print "all fine.'
-------------
This program will crash at the problematic font. Remove it from font 
directory and run again untill it says all fine.
After removing all problematic fonts, Your matplotlib will work.

Thanks.

2005-03-17 01:31, Natsu wrote:
> Hi,
>  After resolving the font_manager.py issue, I could fire up pylab on
>  Japanese Win 2K. However, on my Win XP Japanese PCs, there seems
>  some trouble remaining.
>  
>  The following result was obtained with Enthogut python 2.3.3 on XP
>  professional Version 2002 SP1, Japanese.
>  On other PC with XP SP2, Japanese, I got a similar error.
>  So I"m afraid it is repeatable to any Japanese Win XP.
>  
>  Maybe, my WinXPs are not fresh and clean.  What do you think?
>  I"m ready to test the special debugging build which was mentioned in the
>  list earlier, if the binaries are sent to me.
>  

---
Yasushi Masuda
http://www.cubelab.com/ymasuda/

>>>>> "Scott" == Scott C Splinter <s.c...@la...> writes:

    Scott>          Hi, I am having a problem with legend recognizing
    Scott> the labelsep kwarg.  It recognizes and makes changes

Hey Scott,

This is a bug -- thanks for letting me know.  It will be fixed in the
next release, due out tomorrow, barring unexpected disasters.

JDH