matplotlib-devel Mailing List for matplotlib (Page 2)

John,
I think we really need copy (and maybe deepcopy) functions that work 
with all transforms, not just Separable transforms. This looks fairly 
easy except for one thing: the transform creation functions return 
objects that don't provide any clean way of distinguishing among the 
types of transform. type(trans) reports <type 'Affine'>, regardless of 
what kind of transform it really is. I have not been able to figure out 
where this is coming from. One can't cleanly use hasattr(funcxy) to 
detect a Nonseparable transform because all transforms have the 
attribute, whether they use it or not. I could use "try: 
trans.get_funcxy()" and catch the exception, but that is ugly. (And the 
second time I tried it, it hung ipython.)
I suspect you have thought about this already--do you have any suggested 
solutions? Is there at least a simple way to get type(trans) to work 
right? From the code it looks like it should, so there appears to be a 
bug in the code or in cxx.
Eric

Due to repeated emails by Eric Firing about how something like this
would be nice to have, I finally got around to packaging a little
utility I wrote. I uploaded it to the MPL source repository. The basic
idea is to create a layout engine for matplotlib. Not wanting to
(re-)invent an API, I decided simply to imitate the layout engine I knew
best, which is wxPython.
Disclaimer: This isn't bug-free, complete, or well-documented and this
announcement should merely be taken as a call to "commence hacking now".
That being said, I've used mplsizer for several figures for publication,
so I don't consider it that bad or incomplete, either.
Anyhow, the source code, licensed under the MIT license, is available at:
https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/mplsizer
One note: aside from depending on matplotlib, this requires setuptools.
Sorry to those of you who hate setuptools, but it simply gives me tools
that make my life easier. If you want to change mplsizer to not require
setuptools, that's fine by me, but we should keep it setuptools compatible.
Here's the last part of the demo_basic.py script. "fig" is a matplotlib
Figure instance, "a","b","b2", and "lowest" are matplotlib Axes instances.
 # Now perform the mplsizer stuff
 import matplotlib.toolkits.mplsizer as mplsizer
 frame = mplsizer.MplSizerFrame( fig )
 sizer = mplsizer.MplBoxSizer()
 frame.SetSizer(sizer)
 sizer.Add(a,name='a',expand=1)
 sizer.Add(b,name='b',all=0,left=1,border=0.2)
 sizer.Add(b2,name='b2')
 if more_plots:
 hsizer = mplsizer.MplBoxSizer(orientation='horizontal')
 hsizer.Add(c,name='c',option=1,align_bottom=1)
 hsizer.Add(d,name='d',align_centre=1)
 sizer.Add(hsizer,all=0,bottom=1,border=0.5,expand=1,option=1)
 frame.Layout() # triggers layout
 # It's naughty to use the private attribute, but, hey, this is for
 # debugging only, so it's OK, right?
 lowest.set_position(hsizer._rect)
pylab.show()

Darren,
I don't like the default either--I just left it in place so as not to 
change too many things at once. There is always some tension in mpl 
between doing things the Matlab way, at least by default, and doing 
things better. If there is no opinion to the contrary, I am happy to 
change colorbar defaults for the better. I use the "shrink" kwarg 
routinely to make the colorbar smaller; I think it should be smaller by 
default. I generally prefer a colorbar with a length about 80% that of 
the corresponding image axis length.
What is really needed to optimize it, however, is a smarter axes packing 
algorithm. So far, I have considered it best to at least defer this 
potentially complex change in favor of sticking with simple automatic 
behavior and the present reasonably easy manual configurability. There 
may still be fairly simple ways to improve the default behavior, 
however, beyond picking better default parameters for the present 
algorithms.
The present algorithm divides the figure box in two, with "fraction" 
giving the fraction reserved for the colorbar. The image axes are then 
resized and repositioned within the remainder.
One of the reasons that doing a really good job of automatic colorbar 
sizing and positioning is not trivial is that aspect ratio handling in 
the draw method determines the actual size of the image; to make the 
colorbar match that, we would have to put the colorbar sizing in the 
draw method after the image dimensions have been determined. Probably 
this can all be done cleanly the same sort of Value magic that is used 
in transforms, but I have not tried to figure it out. I think it would 
require setting up some sort of axes drawing order, with care taken to 
avoid circular dependencies.
So, to summarize, I don't mind doing some simple things to make colorbar 
sizing usually look nicer by default, but a more complex and complete 
solution is not high priority for me now.
Eric
Darren Dale wrote:
> I would like to ask about the behavior of colorbar(). In my opinion, the 
> default colorbar is too big. I know the default is similar to matlab's 
> colorbar, but I dont think it should stretch beyond the axes. Also, there is 
> arguably too much space between the colorbar and the right edge of the 
> figure. I'm attaching two pngs, one is the default behavior and the other is 
> my suggested alternative, which I did with colorbar(fraction=0.0305). I don't 
> understand what fraction is scaled to. I expected fraction=1 to make the 
> height equal to the original axes height, but that actually crashes python:
> 
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): St9bad_alloc
> Aborted
> 
> I don't want to seem too critical of the work that has already been put into 
> the colorbar. I just think it needs a bit of polish. Comments?
> 
> Darren
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thursday 27 July 2006 8:33 am, JIM MacDonald wrote:
> Hi,
>
> I've just moved from MATLAB to matplotlib, and I'm really impressed
> with the quality of the PS figures it generates with usetex and the
> xpdf distiller. 
Glad to hear it.
> I've hit a couple of problems though
[...]
> The first problem I noticed is that the distilling process was causing
> some of my images to have (lossy) compression applied and others not.
> It turns out that it is a feature of ps2pdf that it tries to detect
> the content of the image and apply appropriate compression. You can
> over ride this distiller options. My patch adds a new rc option
> ps.image_compression that can be set to auto (preserves the current
> behaviour), DCTEncode (applies lossy JPEG compression), and
> FlateEncode (lossless compression). The distiller commands are
> embedded in the ps file. I looked at making it a flag on each image,
> but couldn't get it to work. Another way to do it is to pass extra
> command line options to ps2pdf (-dAutoFilterColorImages=false
> -sColorImageFilter=FlateEncode should do it for colour images). I
> thought embedding it in the PS file would be more flexible.
I'll look into this soon. I'm hesitant to add another rc option, maybe we can 
consider using these settings as the defaults. I'll post again after I have 
had a chance to play with it.
> My second problem involved the resolutions of the image. I'd like to
> preserve the resolution of my image in the PS output, but I can't
> figure out how to stop the image being resized and interpolated.
> Obviously you need to do this for the bitmap backends, but for vector
> ones surely you can just scale the original image in the vector
> output.
The resolution for Postscript is 72 dpi, and I'm not sure this can be changed. 
Would you send me an example postscript file along with the original png?

Gael Varoquaux wrote:
> Hi,
>
> 	Trying out version 0.87.4 I noticed that the example given on
> pages 
> http://matplotlib.sourceforge.net/screenshots/plotmap.py
> and
> http://scipy.org/Cookbook/Matplotlib/Maps
> fail with :
>
> In [1]: from matplotlib.toolkits.basemap import Basemap
> ---------------------------------------------------------------------------
> exceptions.ImportError Traceback (most
> recent call last)
>
> /home/varoquau/<ipython console>
>
> ImportError: No module named toolkits.basemap
>
> I had a quick look and couldn't find where basemap had gone. How
> should these pages be modified ?
>
> 
Gabriel: Basemap is a separate toolkit - it's not included in 
matplotlib. You can get it from the matplotlib sf project page.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I would like to ask about the behavior of colorbar(). In my opinion, the 
default colorbar is too big. I know the default is similar to matlab's 
colorbar, but I dont think it should stretch beyond the axes. Also, there is 
arguably too much space between the colorbar and the right edge of the 
figure. I'm attaching two pngs, one is the default behavior and the other is 
my suggested alternative, which I did with colorbar(fraction=0.0305). I don't 
understand what fraction is scaled to. I expected fraction=1 to make the 
height equal to the original axes height, but that actually crashes python:
terminate called after throwing an instance of 'std::bad_alloc'
 what(): St9bad_alloc
Aborted
I don't want to seem too critical of the work that has already been put into 
the colorbar. I just think it needs a bit of polish. Comments?
Darren

Hi Stephen,
Yep, ipython is not bad, but it is not really a replacement for a real
IDE. IPython also seems to act a little wanky with graphs to me. For
instance my plots seem to get drawn interactively (read: very
SLOOOOOWLY) when I use the special -pylab mode. Maybe I'm not
configuring ipython properly, but part of my point is that end users
shouldn't have to think about it, and shouldn't need some special
-pylab mode. It should just work. And I think it would if the
displayer's guts were in a completely separate process, acting as a
graph display server.
The only complication I can see is for callbacks from mouse and
keyboard events that occur on the graphs (but does matplotlib even
support that yet?-- I only saw it mentioned on the web page). Those
events would still need to find their way into callbacks in the
original process. But that's doable too, I think. Just use a
separate thread for communication with the graph display server. And
would perhaps be even less painful than dealing with the wx event
loop.
Anyway, it's more of a 'food for thought' suggestion than anything
else. It's not like I'm going to have time to implement it (though it
seems like it would be a fun project if I did have the time).
I am curious as to what the current thinking is about tacking such
event loop issues, though. Surely folks don't think that "use
ipython" is the be-all-and-end-all ultimate solution.
--bb
On 7/26/06, Stephen Walton <ste...@cs...> wrote:
> Bill Baxter wrote:
> > I think all these problems could be fixed if the display interface
> > were turned into a separate process
> Have you tried ipython?
>
> http://ipython.scipy.org/

Hi,
I've just moved from MATLAB to matplotlib, and I'm really impressed
with the quality of the PS figures it generates with usetex and the
xpdf distiller. I've hit a couple of problems though, one I've manged
to solve (patch against 0.87.4 attached) and the other I'd be greatful
if you could help me with please.
I've been using imshow to basically put a set of axes round an image
produced my simulation code. Here's a minimal version of my script:
----------------------------------------------
from pylab import *
rc('text', usetex=True)
rc('ps', usedistiller="xpdf")
figure(1,figsize=(6, 4))
im=imread('image.png') # a 301x318 image
imshow(im,interpolation='nearest',extent=[0.98, 20, 0.01, 0.5])
axis('normal');
savefig('image.eps')
--------------------------------------------
The first problem I noticed is that the distilling process was causing
some of my images to have (lossy) compression applied and others not.
It turns out that it is a feature of ps2pdf that it tries to detect
the content of the image and apply appropriate compression. You can
over ride this distiller options. My patch adds a new rc option
ps.image_compression that can be set to auto (preserves the current
behaviour), DCTEncode (applies lossy JPEG compression), and
FlateEncode (lossless compression). The distiller commands are
embedded in the ps file. I looked at making it a flag on each image,
but couldn't get it to work. Another way to do it is to pass extra
command line options to ps2pdf (-dAutoFilterColorImages=false
 -sColorImageFilter=FlateEncode should do it for colour images). I
thought embedding it in the PS file would be more flexible.
My second problem involved the resolutions of the image. I'd like to
preserve the resolution of my image in the PS output, but I can't
figure out how to stop the image being resized and interpolated.
Obviously you need to do this for the bitmap backends, but for vector
ones surely you can just scale the original image in the vector
output.
Thanks in advance for you help and some great software!
JIM
---

Hi all,
 I would like to enable the key pressed event (key '1' '2' 'a' 'g' .. )
of NavigationToolbar2 in my pyGTK app.
(These keys shortcut are described here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1432252&group_id=80706&atid=560722
)
The shorcuts work perfectly using pylab. But when I include matplotlib in my
pyGTK app the shorcuts are broken.
How could I manage to make them work,
and/or,
where I should start in the source code to undestand how it work, that I
could reproduce the shorkey behavior directly in my own application code?.
Thanks,
David

Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process
Have you tried ipython?
http://ipython.scipy.org/

 Hi,
	Trying out version 0.87.4 I noticed that the example given on
pages=20
http://matplotlib.sourceforge.net/screenshots/plotmap.py
and
http://scipy.org/Cookbook/Matplotlib/Maps
fail with :
In [1]: from matplotlib.toolkits.basemap import Basemap
-------------------------------------------------------------------------=
--
exceptions.ImportError Traceback (most
recent call last)
/home/varoquau/<ipython console>
ImportError: No module named toolkits.basemap
 I had a quick look and couldn't find where basemap had gone. How
should these pages be modified ?
--=20
 Ga=EBl

I'm trying out the brand new python2.5b2. One of the reasons I am =20
excited to upgrade is that ctypes are included in the new python, and =20=
this is pretty hard to get going by hand on the intel Macs because of =20=
an absent libffi. I get
error: invalid conversion from =91const char*=92 to =91char=92
when trying to compile matplotlib on my intel Mac with python 2.5b2. =20=
I don't get a similar error with python 2.4.x. The full output is =20
attached below. I tried to recompile agg.cxx with swig (recompiled =20
to link with python 2.5b2) using this command
python makeswig.py
and I get the same error. BTW, numpy compiles without any =20
complaints, and seems to work just fine. Any ideas?
-Rob
[...copying....]
running build_ext
building 'matplotlib._isnan' extension
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp =20=
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3
creating build/temp.macosx-10.3-fat-2.5
creating build/temp.macosx-10.3-fat-2.5/src
compile options: '-I/usr/local/include -I/usr/include -I. -I/Library/=20
Frameworks/Python.framework/Versions/2.5/include/python2.5 -c'
gcc: src/_isnan.c
In file included from /usr/include/math.h:26,
 from /Library/Frameworks/Python.framework/Versions/=20
2.5/include/python2.5/pyport.h:200,
 from /Library/Frameworks/Python.framework/Versions/=20
2.5/include/python2.5/Python.h:57,
 from src/_isnan.c:1:
/usr/include/architecture/ppc/math.h:477: warning: conflicting types =20
for built-in function =91scalb=92
gcc -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g =20=
-bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.5/src/=20
_isnan.o -L/usr/local/lib -L/usr/lib -o build/lib.macosx-10.3-fat-2.5/=20=
matplotlib/_isnan.so
building 'matplotlib._agg' extension
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp =20=
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3
creating build/temp.macosx-10.3-fat-2.5/agg23
creating build/temp.macosx-10.3-fat-2.5/agg23/src
compile options: '-Iagg23/include -Isrc -Iswig -I/Library/Frameworks/=20
Python.framework/Versions/2.5/include/python2.5 -c'
gcc: agg23/src/agg_rasterizer_scanline_aa.cpp
gcc: agg23/src/agg_curves.cpp
gcc: agg23/src/agg_trans_affine.cpp
gcc: agg23/src/agg_vcgen_dash.cpp
gcc: agg23/src/agg_bezier_arc.cpp
gcc: src/agg.cxx
src/agg.cxx: In function =91int SWIG_Python_ConvertFunctionPtr=20
(PyObject*, void**, swig_type_info*)=92:
src/agg.cxx:2051: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91int SWIG_Python_ConvertFunctionPtr=20
(PyObject*, void**, swig_type_info*)=92:
src/agg.cxx:2051: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91void SWIG_Python_FixMethods(PyMethodDef*, =20=
swig_const_info*, swig_type_info**, swig_type_info**)=92:
src/agg.cxx:31756: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91void SWIG_Python_FixMethods(PyMethodDef*, =20=
swig_const_info*, swig_type_info**, swig_type_info**)=92:
src/agg.cxx:31756: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
lipo: can't figure out the architecture type of: /var/tmp//ccBRU9rF.out
src/agg.cxx: In function =91int SWIG_Python_ConvertFunctionPtr=20
(PyObject*, void**, swig_type_info*)=92:
src/agg.cxx:2051: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91int SWIG_Python_ConvertFunctionPtr=20
(PyObject*, void**, swig_type_info*)=92:
src/agg.cxx:2051: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91void SWIG_Python_FixMethods(PyMethodDef*, =20=
swig_const_info*, swig_type_info**, swig_type_info**)=92:
src/agg.cxx:31756: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
src/agg.cxx: In function =91void SWIG_Python_FixMethods(PyMethodDef*, =20=
swig_const_info*, swig_type_info**, swig_type_info**)=92:
src/agg.cxx:31756: error: invalid conversion from =91const char*=92 to =20=
=91char*=92
lipo: can't figure out the architecture type of: /var/tmp//ccBRU9rF.out
error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/=20
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp =20=
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Iagg23/include -=20=
Isrc -Iswig -I/Library/Frameworks/Python.framework/Versions/2.5/=20
include/python2.5 -c src/agg.cxx -o build/temp.macosx-10.3-fat-2.5/=20
src/agg.o" failed with exit status 1
----
Rob Hetland, Assistant Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamue.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Matplotlib is quite nice, but I keep running into problems with the
actual display interface.
In some cases the plot window freezes and such when using it from a
debugger, or sometimes pylab.show() just never returns. Matlab's
plotting interface just never gave me so much trouble.
I think all these problems could be fixed if the display interface
were turned into a separate process that communicates with the Python
program using pipes or some other IPC mechanism. I used this
technique in a (C/C++) image debugging utility program I wrote
(http://www.billbaxter.com/projects/imdebug) and it works quite well.
The displayer is a separate process using a memory mapped file to
communicate with the main program. When the user's code calls the
"display_image" function, the data to display is copied to the memory
mapped file, the displayer process is sent a signal, and then the
displayer reads the data from the memory mapped file and displays it.
Because the displayer is a separate process, it never hangs, even if
the main app crashes or gets stuck at a break point or in an infinite
loop. And the displayer always owns its display loop completely, so
no nasty issues with who gets to run the wx.App event loop and when,
or with the single-gui-thread limitations you have with multithreaded
GUI apps.
Has anyone given thought to making matplotlib work in such a manner?
It would be hell to do in C or C++ I think, but with Python's
RPC libs I bet it wouldn't be so bad.
--bb

Matplotlib is quite nice, but I keep running into problems with the
actual display interface.
In some cases the plot window freezes and such when using it from a
debugger, or sometimes pylab.show() just never returns. Matlab's
plotting interface just never gave me so much trouble.
I think all these problems could be fixed if the display interface
were turned into a separate process that communicates with the Python
program using pipes or some other IPC mechanism. I used this
technique in a (C/C++) image debugging utility program I wrote
(http://www.billbaxter.com/projects/imdebug) and it works quite well.
The displayer is a separate process using a memory mapped file to
communicate with the main program. When the user's code calls the
"display_image" function, the data to display is copied to the memory
mapped file, the displayer process is sent a signal, and then the
displayer reads the data from the memory mapped file and displays it.
Because the displayer is a separate process, it never hangs, even if
the main app crashes or gets stuck at a break point or in an infinite
loop. And the displayer always owns its display loop completely, so
no nasty issues with who gets to run the wx.App event loop and when,
or with the single-gui-thread limitations you have with multithreaded
GUI apps.
Has anyone given thought to making matplotlib work in such a manner?
It would be hell to do in C or C++ I think, but with Python's
extensive RPC libs I bet it wouldn't be so bad.
Also, once you have that sort of remote operation set up, you can
think about crazy things like just using a web browser as the display
interface. Or remotely displaying graphs on other machines, if you
have some reason to want to do that.
--bb

On 7/24/06, Chris Fonnesbeck <fon...@gm...> wrote:
> On 7/23/06, Charlie Moad <cw...@gm...> wrote:
> > The mingw/2.4 build still works. There are instructions at the top of
> > the setupext.py file. The dll linking error you are getting is
> > something we ran into a lot. If you have numpy installed distutils
> > will use the numpy\distutils\mingw32ccompiler.py file. In the
> > Mingw32CCompiler class remove all links to "msvcr71". In my version
> > of numpy just comment out the whole if block at line 127.
> >
>
> I tried commenting out that very block, but then numpy will not build
> -- it does not see the mingw32 compiler without those lines, it
> appears. I used the --compiler switch on the build, but to no avail.
>
> I'm a bit stuck here, as matplotlib does not build, and the binary
> does not seem to work. I'm trying to put together a package that
> contains numpy, matplotlib and scipy to distribute to some of my
> users.
Try this. If you are still getting an error, please post it. I am
moving this to the devel list.
 if sys.version[:3] > '2.3':
 if libraries:
 pass #libraries.append('msvcr71')
 else:
 libraries = [] #['msvcr71']
The other option is to bundle that dll with matplotlib. I have seen
other python modules doing this.
- Charlie

Steve,
I am aware of the caveats associated with the "name" attribute, which 
is why the code I sent you attempts to do the right thing when it 
doesn't exist. I hadn't considered the case of stdout, but you could 
probably detect situations like that by testing to see if the 
extension is the empty string:
> 	# figure out what the format is
> 	if extension is None or extension == '':
> 		...
However, this variety of special case handling could make things more 
confusing for beginning users. I think ultimately you should do 
whatever you think strikes the best balance between convenience and 
clarity.
On Jul 21, 2006, at 7:27 PM, Steven Chaplin wrote:
>
> I think an explicit 'format' argument is better than reading a 'name'
> attribute which only works sometimes.
In general I tend to agree with you, but I'd like to see Just Work 
when writing to an open file. I don't have a lot of stake in this 
either way, since I spend most of my time with matplotlib pushing the 
RGB data onto wxPython widgets.
Ken

On Fri, 2006年07月21日 at 17:21 -0500, Ken McIvor wrote:
> On Jul 20, 2006, at 7:53 AM, Steven Chaplin wrote:
> >
> > However, print_figure() does not support writing to file objects in
> > different formats because it only takes a 'filename' argument and 
> > does not
> > have an argument to allow you to specify the format.
> 
> You can usually get the filename from the "name" attribute of a file- 
> like object. Below is some untested pseudo-Python code that will use 
> the value of "format" if it's specified and will otherwise try to 
> pull the format from the file name. You should be able to collapse 
> the nested if/else structure -- I've covered all four permutations 
> explicitly for clarity.
> 
> I'm too swamped to put a lot of time into this code/explanation, so 
> please let me know if this doesn't make any sense.
> 
> Ken
> 
> 
> def print_figure(self, fileOrString, format=None):
> 	extension = None
> 
> 	if is_file_like(fileOrString):
> 		filename = getattr(fileobj, 'name', None)
> 	else:
> 		filename = fileOrString
> 
> 	if filename is not None:
> 		# get the extension and make it all lower-case
> 		extension = os.path.splitext(filename, None)
> 
> 	# figure out what the format is
> 	if extension is None:
> 		# no name file, so use format
> 		if format is None:
> 			raise ValueError('you must specify a format')
> 		else:
> 			pass # use the value of "format"				else:
> 		# there's a name, but the format keyword overrides it
> 		if format is None:
> 			# use the file extension
> 			format = extension
> 		else:
> 			pass # use the value of "format"
> 
> 	format = format.lower()
> 	if format not in ('png', 'ps', 'svg'):
> 		raise ValueError('invalid file format %r' % (format,))
> 
> 	# At this point in the method, "format" is the requested file format.
The 'name' attribute is only useful sometimes:
 - it works for file objects (but only when the filename ends with a
format extension)
 - it does not work for sys.stdout, StringIO or cStringIO file-like
objects
I think an explicit 'format' argument is better than reading a 'name'
attribute which only works sometimes.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

I just updated DEVNOTES with the following item:
Make sure sdist builds setuptools-compatible release: Remove setup.cfg
(or, if more than the [egg_info] section is in this file, remove the
[egg_info] section). See
http://mail.python.org/pipermail/distutils-sig/2006-July/006561.html for
more info.

I just updated backend_cairo.py to work with the latest version of pycairo.
The cairo backend can now output PNG, PDF, PS and SVG to a filename or a
file-like object.
However, print_figure() does not support writing to file objects in
different formats because it only takes a 'filename' argument and does not
have an argument to allow you to specify the format.
If the filename is string-like it writes to the filename (and the format is
often encoded into the string, as in 'file.png' for example)
If the filename is not string-like the backend has no way to know which
format is required and has to choose a default format (agg defaults to PNG).
I think print_figure() should be changed from
 print_figure (filename, ...)
to
 print_figure (filename, format='png', ...)
 where format is in ('png', 'ps', 'svg') etc
And savefig() would need a corresponding change.
This would allow backends to write to file-like objects in the requested
format. For example, you could then write to a file-like object in SVG format.
Any comments?
Regards,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

I recently screwed up some of the swig wrappers in trying to hunt down
a memory leak, so if you get segfaults with recent mpl builds, it's my
fault. I think I've fixed the problem, so if you encounter errors,
make sure you are using revision 2581 or later and do a clean rebuild
if necessary by rm -rf ing the build subdir. 
Let me know if you see any strangeness...
JDH

For pie charts, autopct lets a format string with the pie's value be 
printed on the chart. The default fraction of the radius that the text is 
printed at is 0.6; I wanted the text farther out at 0.85.
This small patch (against matplotlib 0.87.4) allows one to customize that 
radius by a new keyword argument, pctradius. The old behavior is still 
the default.
It works with the pylab interface because pylab.pie passes kwargs through.
I would love it if this were accepted into the main tarball; I hereby 
place this patch into the public domain, so there are no copyright 
restrictions on incorporating it into the matplotlib distribution.
Comments/questions welcome. I'm subscribed to matplotlib-devel.
-- Asheesh.
-- 
It is easy to find fault, if one has that disposition. There was once a man
who, not being able to find any other fault with his coal, complained that
there were too many prehistoric toads in it.
 		-- Mark Twain, "Pudd'nhead Wilson's Calendar"

John, Others -
I tried the old style saveas dialogue and it works fine. But the dialogue is
so ugly that I am very hesitant to suggest to switch to the old saveas. I
looked on the web and didn't see any reply to John's post on the python
list. John - you want te repost?
I think Clovis submitted the patch with the new, good looking saveas
dialogue. Do you have any idea Clovis?
Also, I have a Tkinter GUI I wrote that has mpl plots in it, and when I use
saveas from the menubar in that application I don't get this problem. Very
strange....
Mark
On 7/9/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> The weird thing is that this used to work fine in the past.
> Mark> At least, I am pretty sure it did. Then again, I am
> Mark> watching the Worlcup final at this time. So a significant
> Mark> part of my brain is doing something else, Mark
>
> At some point, we upgraded our tk filesave dialog to use the more
> modern one. We could always revert to the old one, which would
> likely fix this but let's give it a day and see if we can't have the
> best of both worlds. Hopefully, the effbot will pick up on my c.l.py
> post...
>
> JDH
>

VGhpcyBpcyB0aGUgcHJvYmxlbToKRm9yIG5vdywgbWF0aHRleHQga25vd3MgYWJvdXQgXGl0ICh0
aGlzIHNob3VsZCBiZSBcbWl0IC0gYXMgaW4gcGxhaW4KVGVYKSwgXHJtLCBcY2FsLCBcdHQgZm9u
dGZhY2UgY29tbWFuZHMuCgpTdXBwb3NlIEkgZGVmaW5lIHRoYXQgXGl0IGlzIG1hcHBlZCB0byBW
ZXJhSXQudHRmIChub3QgaW1wb3J0YW50LCBpdApjb3VsZCBiZSBhbnkgKml0YWxpYyogZm9udCku
CgpSaWdodCBub3csIHdpdGggdGhlIFVuaWNvZGUgZm9udCBjbGFzc2VzLCB0aGUgYmVoYXZpb3Ig
aXM6CiRhYmMkIGdpdmVzICJhYmMiIGluIGl0YWxpYyBzdHlsZS4gQnV0LCBpZiB0aGUgZm9udCBp
cyBkZXNpZ25lZApwcm9wZXJseSwgZXZlbiB0aGUgbWF0aCBzeW1ib2xzIHdvdWxkIGJlIGl0YWxp
Yywgc28gb25lIHdvdWxkIGdldAokXHN1bSQgdG8gYmUgaXRhbGljLCB3aGljaCBzaG91bGQgbm90
IGhhcHBlbi4KClRoYXQncyB3aHkgdGhlIFVuaWNvZGUgc3RhbmRhcmQgZGVmaW5lcyBtYXRoLWl0
YWxpYyBjaGFyYWN0ZXJzIHRvIGJlCmluIHRoZSBVbmljb2RlIFBsYW5lIDEgKDFENDM0IGlzIHVu
aWNvZGUgTUFUSEVNQVRJQ0FMIElUQUxJQyBTTUFMTCBBCmV0Yy4pLCBzbyB0aGV5IGNhbiBiZSBi
dW5kbGVkIHRvZ2V0aGVyIGluIGEgZm9udCB0aGF0IGlzIG5vcm1hbHkKUm9tYW4uIFNvIHRoZSBw
YXJzZXIgc2hvdWxkIHRyYW5zZm9ybSAiYWJjIiB0bwpVIlxVMDAwMUQ0NEVcVTAwMDFENDRGXFUw
MDAxRDQ1MCIgb3IgdG8gc29tZSBhcHJvcHJpYXRlIFRlWCBjb21tYW5kcywKbGlrZSByIlx1bmkx
RDQ0Rlx1bmkxRDQ0Rlx1bmkxRDQ1MCIuIEhvd2V2ZXIsIFRlWCBjb21tYW5kcyBjYW5ub3QKY29u
dGFpbiBudW1iZXJzLCBzbyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2FsbCB0aGVtIFx1bmltaWEs
IFx1bmltaWIsClx1bmltaWMuCgpUaGUgcHJvYmxlbSB3aXRoIHRoZSB1bmljb2RlIHRyYW5zZm9y
bSBpcyB0aGF0LCB1bmRlciB3aW5kb3dzLCBweXRob24KY29udmVydHMgVW5pY29kZSBjaGFycyBv
dXRzaWRlIEJNUCB0byBzdXJyb2dhdGUgcGFpcnMsIHNvCmxlbihVIlxVMDAwMUQ0NEUiKSB3b3Vs
ZCByZXR1cm4gdHdvLCBhbmQgb25lIHdvdWxkIGhhdmUgZGlmZmljdWx0aWVzCnRvIGludGVycHJl
dCB0aGF0IGFzIGEgc2luZ2xlIGNoYXIgLSB3aGljaCBpcyBuZWVkZWQgdG8gcHVsbCB0aGUgZ2x5
cGgKb3V0IG9mIHRoZSBmb250ZmlsZS4gQWdhaW4sIHRoaXMgaXMgbm90IGEgcHJvYmxlbSBpZiB3
ZSBjb252ZXJ0IGFsbAp0aGUgY2hhcmFjdGVycyB0byBzb21lIG1hZGUgdXAgVGVYIGNvbW1hbmRz
LCBhcyBJIHRoZSBvbmVzIGFib3ZlLgoKVGhlIHNhbWUgc2hvdWxkIGJlIGRvbmUgd2l0aCBvdGhl
ciBmb250IHZhcmlhbnRzIGluIG1hdGggbW9kZSAoY2FsLAp0dCwgYm9sZCBldGMuKS4KCkV2ZXJ5
dGhpbmcgd291bGQgYmUgZmluZSBhcyBsb25nIGFzIGFsbCB0aGUgZ2x5cGhzIGFyZSBpbiBvbmUg
ZmlsZS4KSG93ZXZlciwgSSBoYXZlbid0IHN0aWxsIGZvdW5kIGEgZm9udCB0aGF0IGRlZmluZXMg
dGhlIHVuaWNvZGUgYmxvY2s6CjFENDAwLi4xRDdGRjsgTWF0aGVtYXRpY2FsIEFscGhhbnVtZXJp
YyBTeW1ib2xzCmJ1dCBJIHN1cHBvc2UgdGhlIFNUSVggZm9udCB3aWxsIGJlIG9uZSBmaWxlIG9u
bHksIGFuZCB0aGV5IHdpbGwgaGF2ZQpldmVuIHRoYXQgYmxvY2sgcHJvcGVybHkgZGVmaW5lZC4g
SWYgYW55b25lIGtub3dzIGEgZnJlZSBGb250IHRoYXQKZGVmaW5lcyB0aGF0IHJhbmdlLCBwbGVh
c2Ugc3BlYWsgdXAuCgpJZiBldmVyeXRoaW5nIGlzIGluIG9uZSBmb250IGZpbGUsIHRoZW4gdGhl
IGpvYiB3aWxsIGJlIHByZXR0eSBlYXN5LgpCdXQgaWYgdGhlIGdseXBocyBhcmUgc3ByZWFkIGFj
cm9zcyBzZXZlcmFsIGZpbGVzIGl0IHdvdWxkIGJlIGJlc3QgdG8KaGF2ZSBzb21lIFVuaWNvZGUg
YmxvY2sgLT4gZm9udGZpbGUgbWFwcGluZyBzbyBvbmUgY291bGQgc2V0OgowMDAwLi4wMDdGOyBC
YXNpYyBMYXRpbiAtPiBmaWxlMQoyMjAwLi4yMkZGOyBNYXRoZW1hdGljYWwgT3BlcmF0b3JzIC0+
IGZpbGUyCi4uLgoxRDQwMC4uMUQ3RkY7IE1hdGhlbWF0aWNhbCBBbHBoYW51bWVyaWMgU3ltYm9s
cyAtPiBmaWxlbgoKTWF5YmUgdGhpcyBpcyB0aGUgYmVzdCBhcHByb2FjaD8KCkNoZWVycywKRWRp
bgpPbiA3LzE0LzA2LCBKb2huIEh1bnRlciA8amRodW50ZXJAYWNlLmJzZC51Y2hpY2Fnby5lZHU+
IHdyb3RlOgo+ID4+Pj4+ICJFZGluIiA9PSBFZGluIFNhbGtvdmnCpyA8ZWRpbi5zYWxrb3ZpY0Bn
bWFpbC5jb20+IHdyaXRlczoKPiAgICAgRWRpbj4gQ29uY2x1c2lvbiA9PT09PT09PSBKb2huLCB3
aGF0IHNob3VsZCBJIGRvPyBQbGVhc2UgY29tbWVudC4KPgo+IEkgZG9uJ3QgdGhpbmsgd2Ugc2hv
dWxkIGJlIGRpc3RyYWN0ZWQgYnkgVHlwZTEgZm9udHMgb3IgdGhlIGxhY2sgb2YgYQo+IGdvb2Qg
c2V0IG9mIGZyZWUgdW5pY29kZSB0cnVleXBlIG1hdGggZm9udHMuICBXZSB3aWxsIGhhdmUgdGhv
c2Ugc29vbgo+IGVub3VnaCAob3IgYXQgc29tZSBwb2ludCkuICBXaGF0IEkgd291bGQgbGlrZSB0
byBzZWUgaXMgYW4KPiBpbmZyYXN0cnVjdHVyZSB3aGVyZSB0aGUgdXNlciBjYW4gcG9pbnQgdG8g
YW4gYXJiaXRyYXJ5IHNldCBvZiB1bmljb2RlCj4gZm9udHMgYW5kIGhhdmUgbWF0aHRleHQgd29y
ayB3aXRoIHRoYXQgZm9udCBzZXQuICBUaGVuIHdoZW4gdGhlIFNUSVgKPiBvciBzb21lIG90aGVy
IHNldCBvZiB1bmljb2RlIGZvbnRzIGJlY29tZSBhdmFpbGFibGUsIHdlIGNhbiBwb2ludCB0bwo+
IHRoZW0uICBVc2VycyB3aG8gaGF2ZSBwcm9wcmlldGFyeSB1bmljb2RlIG1hdGggZm9udHMgY2Fu
IHVzZSB0aGVtLgo+Cj4gSSBkb24ndCB0aGluayB3ZSBhcmUgYXQgdGhlIHBvaW50IG5vdyB3aGVy
ZSB3ZSBjYW4gZWFzaWx5IHRlc3QKPiBtYXRodGV4dCB3aXRoIGFuIGFyYml0cmFyeSBzZXQgb2Yg
dW5pY29kZSBmb250cy4gIEknZCBsaWtlIHRvIGJlIHRoZXJlCj4gYmVmb3JlIHdlIGdldCBkaXN0
cmFjdGVkIG9uIG90aGVyIHRoaW5ncy4gIE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/Cj4KPiBK
REgKPgo=

John Hunter <jdh...@ac...> writes:
> As you may know, we have a prototype of a PDF backend, though it is
> missing many features.
I've been offline for a while (and will be for at least a week more),
but I hacked a bit more on the PDF backend and just did a commit. Now
it tries to support images and mathtext, but both are incomplete. 
Here's what I think is currently missing:
 * the alpha channel of images is not used (I think this is easy to do)
 * image compression could be improved (PDF supports png-like compression)
 * there are encoding problems in text, especially in mathtext 
 (e.g. \alpha doesn't show up)
 * mathtext positioning seems a bit off
 * no unicode support in text (or mathtext)
 * no Type 1 or Base-14 font support (i.e., "pdf.use_afm")
 * TTF support has lots of small TODOs, e.g. how do you know if a font 
 is serif/sans-serif, or symbolic/non-symbolic?
 * draw_markers, draw_line_collection, etc.
 * use_tex
Perhaps now would be a good time for anyone interested to give the PDF
backend a spin around the block and tell me about any other bugs or
missing features, so when I next do a bout of backend_pdf hacking,
I'll know what people's priorities are.
-- 
Jouni

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 Jeff> John: Yes, I just had a similar problem. Turns out my SF
 Jeff> password had expired. I logged in on the SF web page, and it
 Jeff> prompted me for a new one. After than, SVN worked with the
 Jeff> new password.
Yep, that was it. Thanks!
JDH