matplotlib-devel Mailing List for matplotlib (Page 2)

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
>     Paul> OK, I've created a patch to work around the 'gv' problem for
>     Paul> dense line plots. Attached is a PS file created from this
>     Paul> patch.  Please test to see if it solves your problem.  If it
>     Paul> does, I'll commit the patch to CVS.  It worked for me on
>     Paul> 'ggv'.
> 
> Works for me (also ggv) - what did you do, break up paths longer than
> a certain size into multiple paths?  I need to do the same for agg to
> fix Jin-chung's bug.

Yes.  Paths are divided into mutiple paths of 1000 points (except for the last 
path with can contain upto 1001 points to prevent the last point from being 
orphaned).  This path size seemed like a reasonable number.  I didn't do any 
tests to determine the optimum path size.  From the way gv behaves on my Linux 
box, it appears that 5000 points may be the limit.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> OK, I've created a patch to work around the 'gv' problem for
    Paul> dense line plots. Attached is a PS file created from this
    Paul> patch.  Please test to see if it solves your problem.  If it
    Paul> does, I'll commit the patch to CVS.  It worked for me on
    Paul> 'ggv'.

Works for me (also ggv) - what did you do, break up paths longer than
a certain size into multiple paths?  I need to do the same for agg to
fix Jin-chung's bug.

JDH

Fernando Perez wrote:
> Paul Barrett wrote:
> 
>> I found a bug in the Y-axis scaling.  See the attached PS file.  The 
>> Y-axis scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom).  
>> Instead it is zeros.  Anyone having experience with the scaling code 
>> want to fix this?
>>
>> For those interested, this is a section of the far ultraviolet 
>> spectrum of the variable star SS Cygni (SS Cyg for short) taken by 
>> NASA's Far Ultraviolet Spectroscopic Explorer (FUSE for short).
> 
> 
> Well, I actually tried to see it but gv (Fedora Core 2) chokes on the 
> file: CPU utilization goes to 100% after displaying the axes, labels, 
> and a tiny bit of the graph.  I killed it after a while.
> 
> Are there known problems with the Postscript generated by matplotlib?  
> Can it produce EPS directly (better for publication)?

OK, I've created a patch to work around the 'gv' problem for dense line plots. 
Attached is a PS file created from this patch.  Please test to see if it solves 
your problem.  If it does, I'll commit the patch to CVS.  It worked for me on 'ggv'.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:

    Vittorio> Hi, The debian package has a new address due to recent
    Vittorio> changes on mentors.debian.net.  Instructions for
    Vittorio> installing are now:

    Vittorio> --8<----------------------------------------------------------------------
    Vittorio> * add this lines to your /etc/apt/sources.list: deb
    Vittorio> http://anakonda.altervista.org/debian packages/ deb-src
    Vittorio> http://anakonda.altervista.org/debian sources/ * then
    Vittorio> run: # apt-get update # apt-get install
    Vittorio> python-matplotlib python-matplotlib-doc
    Vittorio> --8<----------------------------------------------------------------------

Thanks Vittorio,

Just for your information, matplotlib no longer requires ttfquery so
you may want to remove this from the debian matplotlib distro.

Thanks!
JDH

On Sat, 2004-08-14 at 11:42,
mat...@li... wrote:
> Hi, I searched for material related to this, but didn't find any, so I 
> hope this isn't a repeat. One feature that has been missing from 
> matplotlib that I find really useful is to print my graphs (I generate a 
> lot, and generally want a hard copy, but not a lot of random files lying 
> around). While on a unix system this is easy to do, I realize it is 
> rather difficult to make crossplatform. So instead I've been hacking the 
> source and adding my own button in. However, with each release this can 
> get a bit tiresome, so the idea occured to me that it would be nice if I 
> have a function to add buttons to the toolbar that could then run 
> arbritrary code.
> 
> I can submit my code if anyone is interested (it's a very rough hack, 
> and only for the GTK backend), but the idea is that in my own code I can 
> just do:
> 
> def myprint(*args, **kwargs):
>   fd, path = tempfile.mkstemp(suffix=".eps", dir="/tmp")
> 
>   savefig(path)
>   print "lpr %s" % path
>   os.system("lpr %s" % path)
> 
>   os.close(fd)
>   os.unlink(path)
> 
> 
> and later on:
> 
> add_toolbar_button("print", "prints figure", gtk.STOCK_PRINT, myprint)
> 
> I was curious as to what other people thought of this, and whether it 
> had a chance of ending up in matplotlib (being able to add other widgets 
> besides buttons would be extra cool).

Perhaps the .matplotlibrc file could have lines like
printcommand: None
printcommand: '"lpr %s" % path'
And if printcommand is not None an extra toolbar button is created which
calls 
os.system(printcommand)
to print the file.

Steve

Hi, I searched for material related to this, but didn't find any, so I 
hope this isn't a repeat. One feature that has been missing from 
matplotlib that I find really useful is to print my graphs (I generate a 
lot, and generally want a hard copy, but not a lot of random files lying 
around). While on a unix system this is easy to do, I realize it is 
rather difficult to make crossplatform. So instead I've been hacking the 
source and adding my own button in. However, with each release this can 
get a bit tiresome, so the idea occured to me that it would be nice if I 
have a function to add buttons to the toolbar that could then run 
arbritrary code.

I can submit my code if anyone is interested (it's a very rough hack, 
and only for the GTK backend), but the idea is that in my own code I can 
just do:

def myprint(*args, **kwargs):
  fd, path = tempfile.mkstemp(suffix=".eps", dir="/tmp")

  savefig(path)
  print "lpr %s" % path
  os.system("lpr %s" % path)

  os.close(fd)
  os.unlink(path)


and later on:

add_toolbar_button("print", "prints figure", gtk.STOCK_PRINT, myprint)

I was curious as to what other people thought of this, and whether it 
had a chance of ending up in matplotlib (being able to add other widgets 
besides buttons would be extra cool).

Abe

p.s. Matplotlib is great! Never having to go near matlab again makes me 
happy just thinking about it. Thanks for the great work!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
The debian package has a new address due to recent changes on mentors.debian.net.
Instructions for installing are now:

- --8<----------------------------------------------------------------------
* add this lines to your /etc/apt/sources.list:
  deb http://anakonda.altervista.org/debian packages/
  deb-src http://anakonda.altervista.org/debian sources/
* then run:
  # apt-get update
  # apt-get install python-matplotlib python-matplotlib-doc
- --8<----------------------------------------------------------------------




- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBHR2fpT6bvDtyXOIRAmEFAJ9+T6EHRTVksp2oapB2KwF6eB0KkQCgkQid
zNg2B1ZEoKTiFUPEKyFT9yk=
=mxaZ
-----END PGP SIGNATURE-----
 

 

 --

 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 

 Sponsor:

 Telefonare all'estero risparmiando fino all'80%? Con Email.it Phone Card puoi, clicca e scopri tutti i vantaggi

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2683&d=13-8

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> OK. I made the changes that Darren Dale suggested and the
    Paul> plot now looks good.

Great, I take it you'll commit these to CVS....

    Paul> Done. The file is uploaded.

OK, thanks.  I'll see if I can get any insight into the PS bug.  It
may be, as you suggest, a line size issue.  That looked like a pretty
dense spectrum you plotted.

If you were following the user list, Jin-chung found a pathological
case where the agg renderer runs out of ink for extremely long dense
paths that cover over 4 Mega-pixels with ink.  His problem can be
solved by breaking up really long paths into separate paths (not
implemented yet).  It may be that the same thing is needed in
backend_ps to accommodate gv.

JDH

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> 
>     Paul> No, the latest CVS still shows the bug.
> 
> I haven't included his changes yet so you would have had to add the
> code yourself.  I can take a look later though.

OK. I made the changes that Darren Dale suggested and the plot now looks good.

>     >> Otherwise, if you can send me a tarball which has a script and
>     >> some data so I can replicate the bug, I'll take a look.  These
>     >> bugs are easier to fix if you have something to test against.
> 
>     Paul> Attached is the data (FITS) file and the following are the
>     Paul> commands that I use to plot the data.  You may need to
>     Paul> download the pyfits module to access the file.
> 
> I don't think your data file came through properly.  You may want to
> upload it to http://nitace.bsd.uchicago.edu:8080/files/share

Done. The file is uploaded.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:


    Paul> No, the latest CVS still shows the bug.

I haven't included his changes yet so you would have had to add the
code yourself.  I can take a look later though.

    >> Otherwise, if you can send me a tarball which has a script and
    >> some data so I can replicate the bug, I'll take a look.  These
    >> bugs are easier to fix if you have something to test against.

    Paul> Attached is the data (FITS) file and the following are the
    Paul> commands that I use to plot the data.  You may need to
    Paul> download the pyfits module to access the file.

I don't think your data file came through properly.  You may want to
upload it to http://nitace.bsd.uchicago.edu:8080/files/share

    Paul> Thanks for taking a look at this.

No problem...

JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> 
>     Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
>     Fernando> chokes on the file: CPU utilization goes to 100% after
>     Fernando> displaying the axes, labels, and a tiny bit of the
>     Fernando> graph.  I killed it after a while.
> 
> I had the same problem with ggv (but I converted it with ps2pdf and
> viewed it as pdf).  What are you using as a PS viewer Paul?

GGV (i.e. Gnome ghostview)

> One thing that concerns about embedding truetype fonts in PS figures
> is that they don't look very good in standard viewers (xdvi, ggv)
> though they seem to print fine, at least on the printers I've tried.
> It may be that the viewers don't have very good truetype rendering
> algorithms.

It might also be the standard fonts that we use.  In other words, there might be 
other truetype fonts that render better with freetype2.

> I'm on the fence about whether we should revert to the afm fonts for
> plain text in PS, and just use truetype for mathtext and if
> explicitly requested using a yet-to-be-determined mechanism.  These
> certainly look better in the PS viewers I've tried.  Of course the
> truetype fonts offer the same look and feel across backends, which is
> why I am on the fence.  Any opinions here?

I don't see a gain here, since PS output is mainly for printing where the fonts 
look fine.  Maybe we should invest more effort in a PDF backend, which displays 
better in a viewer and also does the conversion to PS.  Or switch to TTF that 
render better in a viewer, such as the core MS TT fonts.

>     Fernando> Are there known problems with the Postscript generated
>     Fernando> by matplotlib?  Can it produce EPS directly (better for
>     Fernando> publication)?
> 
> EPS: yes - just save as *.eps from just about any backend.
> 
> The only reported problem I've heard was a post from Flavio Coelho
> 
>   While on the same topic, I had some problems inserting matplotlib
>   generated PS plots into TeXMacs, although they open normally in gv,
>   for instance. have you have seen any compatibility issues for the PS
>   files and other PS viewing programs?  Running ps2ps on the
>   matplotlib PS files resolved the problem. However I wanted to use
>   TexMacs as a frontend to use matplotlib interactively...
> 
> Paul, so we could help narrow this problem with gv and your figure,
> could you try generating it with 0.60.2 (which uses AFM if I recall
> correctly) to see if it is related to the new font handling in PS?

I'll take a look at it.  However, I suspect the fonts are not the problem, since 
each font only increases the size of the PS file by about 60 kBs.  I suspect it 
is the size of the data and the rendering code that is causing the problem.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
>     Paul> I found a bug in the Y-axis scaling.  See the attached PS
>     Paul> file.  The Y-axis scale should go from 0. to 2.0e-11 (in
>     Paul> ergs/cm**2/s/Angstrom).  Instead it is zeros.  Anyone having
>     Paul> experience with the scaling code want to fix this?
> 
> Darren Dale posted a small fix related to ticking for exponentially
> formatted data to the users list today - you may want to see if that
> helps.

No, the latest CVS still shows the bug.

> Otherwise, if you can send me a tarball which has a script and some
> data so I can replicate the bug, I'll take a look.  These bugs are
> easier to fix if you have something to test against.

Attached is the data (FITS) file and the following are the commands that I use 
to plot the data.  You may need to download the pyfits module to access the file.

 >>> import pyfits
 >>> from matplotlib.matlab import *
 >>> fits = pyfits.open('C05302010011alif4ttagfcal.fit')
 >>> data = fits[1].data.field
 >>> plot(data('wave'), data('flux'))
[<matplotlib.lines.Line2D instance at 0x40da5c4c>]
 >>> show()


Thanks for taking a look at this.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

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


    Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
    Fernando> chokes on the file: CPU utilization goes to 100% after
    Fernando> displaying the axes, labels, and a tiny bit of the
    Fernando> graph.  I killed it after a while.

I had the same problem with ggv (but I converted it with ps2pdf and
viewed it as pdf).  What are you using as a PS viewer Paul?

One thing that concerns about embedding truetype fonts in PS figures
is that they don't look very good in standard viewers (xdvi, ggv)
though they seem to print fine, at least on the printers I've tried.
It may be that the viewers don't have very good truetype rendering
algorithms.

I'm on the fence about whether we should revert to the afm fonts for
plain text in PS, and just use truetype for mathtext and if
explicitly requested using a yet-to-be-determined mechanism.  These
certainly look better in the PS viewers I've tried.  Of course the
truetype fonts offer the same look and feel across backends, which is
why I am on the fence.  Any opinions here?

    Fernando> Are there known problems with the Postscript generated
    Fernando> by matplotlib?  Can it produce EPS directly (better for
    Fernando> publication)?

EPS: yes - just save as *.eps from just about any backend.

The only reported problem I've heard was a post from Flavio Coelho

  While on the same topic, I had some problems inserting matplotlib
  generated PS plots into TeXMacs, although they open normally in gv,
  for instance. have you have seen any compatibility issues for the PS
  files and other PS viewing programs?  Running ps2ps on the
  matplotlib PS files resolved the problem. However I wanted to use
  TexMacs as a frontend to use matplotlib interactively...

Paul, so we could help narrow this problem with gv and your figure,
could you try generating it with 0.60.2 (which uses AFM if I recall
correctly) to see if it is related to the new font handling in PS?

Thanks,
JDH

Paul Barrett wrote:

> Yes, I have the same problem with ggv.  However, it prints fine on a PS printer, 
> so I think it's ghostview.

Mmh.  It still might be worth looking into.  Even if it's a ghostview problem, 
  it might be possible to generate 'friendlier' PS code that doesn't kill 
ghostview so badly.  As people start using matplotlib for generating EPS plots 
which will go into papers, the "if you can't preview it just print it" answer 
is going to make quite a few unhappy campers, I suspect.

I know it sucks to code around the bugs of other code, but given that 
ghostview is the near-universally available tool (I checked the problem 
against RedHat 9, Fedora 1 and Fedora 2), matplotlib might want to bow a bit 
in this case :)

Just a suggestion.

Best,

f

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> I found a bug in the Y-axis scaling.  See the attached PS
    Paul> file.  The Y-axis scale should go from 0. to 2.0e-11 (in
    Paul> ergs/cm**2/s/Angstrom).  Instead it is zeros.  Anyone having
    Paul> experience with the scaling code want to fix this?

Darren Dale posted a small fix related to ticking for exponentially
formatted data to the users list today - you may want to see if that
helps.

Otherwise, if you can send me a tarball which has a script and some
data so I can replicate the bug, I'll take a look.  These bugs are
easier to fix if you have something to test against.

JDH

    Paul> For those interested, this is a section of the far
    Paul> ultraviolet spectrum of the variable star SS Cygni (SS Cyg
    Paul> for short) taken by NASA's Far Ultraviolet Spectroscopic
    Paul> Explorer (FUSE for short).

    Paul>   -- Paul

    Paul> -- Paul Barrett, PhD Space Telescope Science Institute
    Paul> Phone: 410-338-4475 ESS/Science Software Branch FAX:
    Paul> 410-338-4767 Baltimore, MD 21218

Paul Barrett wrote:
> I found a bug in the Y-axis scaling.  See the attached PS file.  The Y-axis 
> scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom).  Instead it is 
> zeros.  Anyone having experience with the scaling code want to fix this?
> 
> For those interested, this is a section of the far ultraviolet spectrum of the 
> variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
> Spectroscopic Explorer (FUSE for short).

Well, I actually tried to see it but gv (Fedora Core 2) chokes on the file: 
CPU utilization goes to 100% after displaying the axes, labels, and a tiny bit 
of the graph.  I killed it after a while.

Are there known problems with the Postscript generated by matplotlib?  Can it 
produce EPS directly (better for publication)?

Cheers,

f

I found a bug in the Y-axis scaling.  See the attached PS file.  The Y-axis 
scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom).  Instead it is 
zeros.  Anyone having experience with the scaling code want to fix this?

For those interested, this is a section of the far ultraviolet spectrum of the 
variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
Spectroscopic Explorer (FUSE for short).

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

John Hunter wrote:
> What's new in matplotlib-0.61.0 - 

>  * You can put a .matplotlibrc file in a dir to override the one in
>    your HOME dir.  If you have a project, say a book, and you want to
>    make a bunch of images with the same look and feel for the book,
>    you can place a custom rc file in the code dir for that book and
>    this won't affect the configs you use for normal, interactive use.

Just a question/suggestion on this.  Is there any user-available function to 
load matplotlibrc files?  Instead of relying on .files (hidden from normal ls 
calls), it would be nice if _any_ file could live in a directory defining this 
configuration.  One could then in a script for a specific project write:

load_rc('myproject_matplolibrc')
...

This would even allow you to cleanly maintain multiple rc files in the same 
directory, in case you want.  I also think it serves better the 'explicit is 
better than implicit' python mantra: I'd even prefer NOT to have silent 
loading of .matplotlibrc files beyond that in ~/, since this would mean that 
matplotlib will behave differently depending on where you start it.  I think 
this can be confusing.

Just having an available loadrc() routine would solve the surprise issue, 
allow multiple rc files per directory (for interactive and publication work, 
for example), and the user cost would remain minimal: just a simple function 
call to do the loading.

Just some ideas...

Best,

f

What's new in matplotlib-0.61.0 - 

  Note win32 pygtk users - if you encounter problems or errors related
  to svg loading, see note at end of this email.

You can read these announce notes in html with hyperlinks at
http://matplotlib.sf.net/whats_new.html.

 * A new, enhanced, navigation toolbar.  Set 'toolbar : toolbar2' in
   matplotlibrc to try it out.  Tutorial on the new toolbar is at
   http://matplotlib.sf.net/tutorial.html#toolbar2.  Note that this
   toolbar behaves very differently than the classic toolbar.  To use
   it, you must click on the pan/zoom or zoom to rect and then
   interact with the axes by dragging your mouse over it.  The
   'forward', 'back' and 'home' buttons are used to navigate between
   previously defined view limits.  At some point we'll add multiple
   simultaneous axes support for the new toolbar but we're still
   mulling over the interface - if you need it you can still uses
   toolbar : classic.

 * Mathtext for PS!!!  Also, PS now embeds TrueType fonts so the same
   fonts you use in the *Agg GUIs should be displayed in PS
   output. Thanks Paul Barrett!

 * The imread function is used to load PNGs into arrays.  I'd like to
   add more image loaders and savers down the road -
   http://matplotlib.sourceforge.net/matplotlib.matlab.html#-imread

 * New event handling.  The functions mpl_connect and mpl_disconnect
   are used for backend independent event handling.  The callback
   signature is func(event).  See
   http://matplotlib.sf.net/tutorial.html#events and
   http://matplotlib.sf.net/examples/coords_demo.py.  The new events
   carry lots of useful information in them, like the coords in
   display and data units, the axes instance they were over, keys
   pressed during the event and more.

 * Many fixes to the SVG backend, including page layout, font support
   and image support.  SVG is now considered alpha.  You can save
   ps/eps/svg figures from GUI backends by providing the right
   extensions.  SVG is currently the fastest backend in my tests.

 * More memory leaks fixed - see
   http://matplotlib.sourceforge.net/faq.html#LEAKS for details.  My
   estimate is that complex figures (multiple subplots, images, etc..)
   now leak no more than 10-50 bytes per figure.  Down from several
   hundred bytes per figure in 0.60.

 * Vertical mathtext in backend_agg (ylabels now work properly!).
   mathtext with arbitrary rotations in PS.  Thanks Jim Benson and
   Paul Barrett!

 * Added some abbrev functions in matplotlib.lines, mainly for
   interactive users trying to save key strokes.  markerfacecolor is a
   lot of keys!  For lines, these abbrevs were added

        aa  : antialiased
        c   : color
        ls  : linestyle
        lw  : linewidth
        mec : markeredgecolor
        mew : markeredgewidth
        mfc : markerfacecolor
        ms  : markersize

   Thus you can type --not necessarily recommended for readability in
   scripts or apps but great for throwaway use in interactive shells
    
    # no antialiasing, thick green markeredge lines
    >>> plot(range(10), 'ro', aa=False, mew=2, mec='g')

   Analogs in matplotlib.patches

        aa  : antialiased
        lw  : linewidth
        ec  : edgecolor
        fc  : facecolor

 * You can put a .matplotlibrc file in a dir to override the one in
   your HOME dir.  If you have a project, say a book, and you want to
   make a bunch of images with the same look and feel for the book,
   you can place a custom rc file in the code dir for that book and
   this won't affect the configs you use for normal, interactive use.

 * Updated installing instructions at
   http://matplotlib.sf.net/installing.html (see also INSTALL in src
   distro).  Fixed a tk/osx install problem in setupext.py

 * New demo for wx/wxagg showing how to to make a flicker free cursor
   that follows the mouse and reports the coords in a status bar - see
   http://matplotlib.sf.net/examples/wxcursor_demo.py

 * Numerous bug fixes and minor enhancements detailed at
   http://matplotlib.sf.net/CHANGELOG

Downloads at http://sourceforge.net/projects/matplotlib


pygtk / win32 bug

  Alas, an enterprising matplotlib user found a bug in matplotlib-0.61
  on win32 with recent versions of pygtk even before the announcement.
  Sigh.  Is it just me or is testing multiple GUIs with multiple,
  incompatible versions on multiple platforms a pain?  

  Apparently this bug is only exposed on recent versions of pygtk for
  win32.  If you encounter problems, try removing or commenting out
  the last lines of site-packages\matplotlib\backends\backend_gtk.py
  which set the matplotlib minimization icon.  Eg, triple quote

"""
# set icon used when windows are minimized
if gtk.pygtk_version >= (2,2,0):
    basedir = matplotlib.rcParams['datapath']
    fname = os.path.join(basedir, 'matplotlib.svg')
    try:   gtk.window_set_default_icon_from_file (fname)
    except gobject.GError, exc: print >>sys.stderr, exc
"""