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
"""