matplotlib-devel Mailing List for matplotlib (Page 464)

    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

John Hunter wrote:
> I'm getting prompted for username and password when I try and commit
> (normally I am not prompted since they are stored), and am not given
> access when I give them
>
> Authentication realm: <https://svn.sourceforge.net:443> SourceForge
> Subversion area
> Username: svn: Commit failed (details follow):
> svn: MKACTIVITY of
> '/svnroot/matplotlib/!svn/act/e139267f-8d18-0410-9ae4-f3e99be941f3':
> authorization failed (https://svn.sourceforge.net)
>
> Anyone else having problems, or aware of any issues?
>
> JDH
>
>   


John:  Yes, I just had a similar problem. Turns out my SF password had 
expired. I logged in on the SF web page, and it prompted me for a new 
one.  After than, SVN worked with the new password.

-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'm getting prompted for username and password when I try and commit
(normally I am not prompted since they are stored), and am not given
access when I give them

Authentication realm: <https://svn.sourceforge.net:443> SourceForge
Subversion area
Username: svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/matplotlib/!svn/act/e139267f-8d18-0410-9ae4-f3e99be941f3':
authorization failed (https://svn.sourceforge.net)

Anyone else having problems, or aware of any issues?

JDH

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
    Edin> Conclusion =3D=3D=3D=3D=3D=3D=3D=3D John, what should I do? Ple=
ase comment.

I don't think we should be distracted by Type1 fonts or the lack of a
good set of free unicode trueype math fonts.  We will have those soon
enough (or at some point).  What I would like to see is an
infrastructure where the user can point to an arbitrary set of unicode
fonts and have mathtext work with that font set.  Then when the STIX
or some other set of unicode fonts become available, we can point to
them.  Users who have proprietary unicode math fonts can use them.

I don't think we are at the point now where we can easily test
mathtext with an arbitrary set of unicode fonts.  I'd like to be there
before we get distracted on other things.  Or am I missing something?

JDH

On Wednesday 12 July 2006 07:10, Edin Salkovi=C4=87 wrote:
> After some thorough research on the subject I decided to post my
> conclusions/thoughts here. Beware, this is a long one.
>
> Font problems
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> There are no good, complete, free, unicode, Open/TrueType math fonts
> currently. We will have to wait for the STIX fonts.

The STIX fonts have been delayed a number of times, but they just received =
the=20
last set of glyphs. This is good news.

    Due to a change of plan I won't be stuck in a library this
afternoon, so I won't be working on this transfer, but I am still
interested to now weather others agree that it would be useful to port
this part of the matplotlib website on the scipy wiki.

    Gael

    Hello list,

	I would like to move the "screenshot" section of the matplotlib
web site to the scipy.org wiki. The reason I suggest this is that I
think that we effectively have a 2 cookbooks in 2 different places. Is
anybody opposed to this ? I will be stuck in a library with not much to
do in a few hours, so I think I will start working on that.

    Gael

QWZ0ZXIgc29tZSB0aG9yb3VnaCByZXNlYXJjaCBvbiB0aGUgc3ViamVjdCBJIGRlY2lkZWQgdG8g
cG9zdCBteQpjb25jbHVzaW9ucy90aG91Z2h0cyBoZXJlLiBCZXdhcmUsIHRoaXMgaXMgYSBsb25n
IG9uZS4KCkZvbnQgcHJvYmxlbXMKPT09PT09PT09PQpUaGVyZSBhcmUgbm8gZ29vZCwgY29tcGxl
dGUsIGZyZWUsIHVuaWNvZGUsIE9wZW4vVHJ1ZVR5cGUgbWF0aCBmb250cwpjdXJyZW50bHkuIFdl
IHdpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUgU1RJWCBmb250cy4gT24gdGhlIHNpdGUgaXQKc2F5
cyB0aGF0IHRoZSBiZXRhIHZlcnNpb24gb2YgdGhlIGZvbnRzIHdpbGwgYmUgYXZhaWxhYmxlIGlu
CnNlcHRlbWJlciwgc28gcHJvYmFibHkgdGhlIG5leHQgU29DIGNvdWxkIGNvdmVyIHRoYXQgLSBp
ZiB3ZSdyZSBsdWNreQo7KS4KCkkgaGFkIGEgbG9vayBhdCB0aGUgZm9sbG93aW5nIE9wZW4vVHJ1
ZVR5cGUgdW5pY29kZSBmb250czoKICogQ01VIGZvbnRzLiBUaGlzIGZvbnRzIHByYWN0aWNhbHkg
ZG9uJ3QgaGF2ZSBhbnkgbWF0aCBzeW1ib2xzLCBzbwp0aGV5J3JlIG5vdCBhIHNvbHV0aW9uLgog
KiBUaGUgZm9udHMgdXNlZCBieSBPcGVuIE9mZmljZSAtIE9wZW4gU3ltYm9sIChvcGVuc19fXy50
dGYpLCB3aGljaApoYXMgYSBkZWNlbnQgc2V0IG9mIHN5bWJvbHMgKHVuaWNvZGUpLiBUaGlzIGZv
bnRzIHdlcmUgbWFkZSB0byBwbGF5CndlbGwgd2l0aCBUaW1lcywgYW5kIGNvdWxkIGJlIHVzZWQg
aW4gbWF0aHRleHQgd2l0aCBwZXJoYXBzIE5pbWJ1cwpSb21hbiBmb250cy4KICogRnJlZUZvbnQu
IEdQTCBmb250cywgYXZhaWxhYmxlIG9uIGFueSBMaW51eCBib3guIFRoZXkgaGF2ZSBhbgpleHRl
bnNpdmUgbGlzdCBvZiBzdXBwb3J0ZWQgc3ltYm9scy4gUHJvYmFibHkgdGhlIGJlc3QgZnJlZSBU
cnVlVHlwZQpmb250cyBvdXQgdGhlcmUuCgpUaGUgYmVzdCBzb2x1dGlvbiB0byB0aGUgcHJvYmxl
bSBvZiBnb29kIGZvbnRzIHdvdWxkIGJlIHVzaW5nIHRoZQpjdXJyZW50bHkgYXZhaWxhYmxlIENN
IGFuZCBBTVMgKGFuZCBvdGhlcikgVHlwZTEgZm9udHMgd2hpY2ggYXJlIGZyZWUKYW5kIGNvbWUg
d2l0aCBldmVyeSBUZVggZGlzdHJpYnV0aW9uLiBUaGVzZSBmb250cyBhcmUgY29tcGxldGUsIGFu
ZApoYXZlIHByZXR0eSBnb29kIFVuaWNvZGUgc3VwcG9ydCB3aGljaCBpcyBpbHVzdHJhdGVkIGJ5
IHRoZSBmb2xsb3dpbmcKY29kZToKCmZyb20gbWF0cGxvdGxpYi5mdDJmb250IGltcG9ydCBGVDJG
b250CmltcG9ydCB1bmljb2RlZGF0YQoKIyBQYXRoIHRvIGEgVHlwZTEgZm9udApmaWxlbmFtZSA9
IHInYzpcdGV4bWZcZm9udHNcdHlwZTFcYmx1ZXNreVxzeW1ib2xzXG1zYW0xMC5wZmInCgpmID0g
RlQyRm9udChmaWxlbmFtZSkKaW5kZXhlcyA9IGYuZ2V0X2NoYXJtYXAoKQpmb3IgaW5kZXgsIHVu
aSBpbiBpbmRleGVzLml0ZW1zKCk6CiAgICB0cnk6CiAgICAgICAgbmFtZSA9IHVuaWNvZGVkYXRh
Lm5hbWUodW5pY2hyKHVuaSkpCiAgICBleGNlcHQgVmFsdWVFcnJvcjoKICAgICAgICBuYW1lID0g
Tm9uZQogICAgcHJpbnQgZi5nZXRfZ2x5cGhfbmFtZShpbmRleCksIGluZGV4LCBuYW1lLCByZXBy
KHVuaWNocih1bmkpKQoKd2hpY2ggb3V0cHV0cwoKc3BhY2UgMTI4IFNQQUNFIHUnICcKZGlhbW9u
ZCA2IEJMQUNLIERJQU1PTkQgU1VJVCB1J1x1MjY2NicKdGhlcmVmb3JlIDQxIFRIRVJFRk9SRSB1
J1x1MjIzNCcKYmVjYXVzZSA0MiBCRUNBVVNFIHUnXHUyMjM1JwptdWNobGVzcyAxMTAgTVVDSCBM
RVNTLVRIQU4gdSdcdTIyNmEnCm11Y2hncmVhdGVyIDExMSBNVUNIIEdSRUFURVItVEhBTiB1J1x1
MjI2YicKZGJsYXJyb3dsZWZ0IDE4IExFRlQgUklHSFQgRE9VQkxFIEFSUk9XIHUnXHUyMWQ0Jwpk
YmxhcnJvd3JpZ2h0IDE5IFJJR0hUV0FSRFMgRE9VQkxFIEFSUk9XIHUnXHUyMWQyJwpsZXNzb3Jn
cmVhdGVyIDU1IExFU1MtVEhBTiBPUiBHUkVBVEVSLVRIQU4gdSdcdTIyNzYnCmdyZWF0ZXJvcmxl
c3MgNjMgR1JFQVRFUi1USEFOIE9SIExFU1MtVEhBTiB1J1x1MjI3NycKYW5nbGUgOTIgQU5HTEUg
dSdcdTIyMjAnCnByb3BvcnRpb25hbCA5NSBQUk9QT1JUSU9OQUwgVE8gdSdcdTIyMWQnCgptc2Ft
MTAgZm9udCB3YXMgdXNlZCBpbiB0aGUgYWJvdmUgY29kZSwgYnV0IG90aGVyIGZvbnRzIGJlaGF2
ZSBzaW1pbGFybHkuCgpVbmZvcnR1bmF0ZWx5IHRoZSBtb3N0IGltcG9ydGFudCBmdW5jdGlvbiBp
biBGVDJGb250IGNsYXNzCgpmLmdldF9nbHlwaChpbmRleCkKCnJhaXNlcwoKVmFsdWVFcnJvcjog
R2x5cGggaW5kZXggb3V0IG9mIHJhbmdlCgpmb3IgVHlwZTEgZm9udHMsIGJ1dCBJIHRoaW5rIHRo
YXQgdGhpcyBjb3VsZCBiZSBlYXNpbHkgZml4ZWQuCgpDdXJyZW50IEMrKyBjb2RlIGZvciBnZXRf
Z2x5cGg6CmNoYXIgRlQyRm9udDo6Z2V0X2dseXBoX19kb2NfX1tdID0KImdldF9nbHlwaChudW0p
XG4iCiJcbiIKIlJldHVybiB0aGUgZ2x5cGggb2JqZWN0IHdpdGggbnVtIG51bVxuIgo7ClB5OjpP
YmplY3QKRlQyRm9udDo6Z2V0X2dseXBoKGNvbnN0IFB5OjpUdXBsZSAmIGFyZ3MpewogIF9WRVJC
T1NFKCJGVDJGb250OjpnZXRfZ2x5cGgiKTsKCiAgYXJncy52ZXJpZnlfbGVuZ3RoKDEpOwogIGlu
dCBudW0gPSBQeTo6SW50KGFyZ3NbMF0pOwoKICBpZiAoIChzaXplX3QpbnVtID49IGdtcy5zaXpl
KCkpCiAgICB0aHJvdyBQeTo6VmFsdWVFcnJvcigiR2x5cGggaW5kZXggb3V0IG9mIHJhbmdlIik7
CgogIC8vdG9kbzogcmVmY291bnQ/CiAgcmV0dXJuIFB5Ojphc09iamVjdChnbXNbbnVtXSk7Cn0K
ClRoZSBwcm9ibGVtIHdpdGggdGhpcyBzb2x1dGlvbiAoaWYgd2UgZ2V0IGdldF9nbHlwaCB0byB3
b3JrIHdpdGgKVHlwZTEpIGNvdWxkIGJlIHRoZSBiYWNrZW5kcy4gQWdnIHdvdWxkbid0IGhhdmUg
dG8gY2hhbmdlIG11Y2ggKGlmIGF0CmFsbCksIGJ1dCBJIGRvbid0IGtub3cgYWJvdXQgdGhlIFBT
IGFuZCBTVkcgYmFja2VuZHMuIFR5cGUgMSBmb250cyBhcmUKaW5zdGFsbGFibGUgb24gYm90aCB3
aW5kb3dzICh2aWEgLnBmbSBmaWxlcykgYW5kIFVuaXggc3lzdGVtcywgc28gSQpndWVzcyBTVkcg
ZmlsZXMgY291bGQgYmUgdmlld2VkL2NoYW5nZWQgd2l0aG91dCBtdWNoIGhhc3NsZSwgYW5kIHRo
ZQpQUyBiYWNrZW5kIGNvdWxkIGJlIGNoYW5nZWQgYSBiaXQgdG8gc3VwcG9ydCBUeXBlMSBmb250
cy4KCkFsc28sIGFsbCB0aGUgY2hhcmFjdGVycyBhcmUgc3ByZWFkIGFyb3VuZCBpbiBhIHByZXR0
eSBsYXJnZSBudW1iZXIgb2YKZmlsZXMsIGJ1dCBJIHN1cHBvc2UgdGhhdCB3aXRoIGEgbGl0dGxl
IGNvZGUgdGhpcyBjYW4gYmUgc3VycGFzc2VkLgoKVW5pY29kZSBwcm9ibGVtcwo9PT09PT09PT09
PT09ClRoZSBmb2xsb3dpbmcgaXMgYXNzZW1ibGVkIGZyb20gdGhlIHJlcG9ydCDCuCJVbmljb2Rl
IFN1cHBvcnQgZm9yCk1hdGhlbWF0aWNzIiwgd2hpY2ggaXMgdGhlIGZpcnN0IHNvdXJjZSBvZiBp
bmZvcm1hdGlvbiByZWdhcmRpbmcKbWF0aGVtYXRpY3MgYW5kIFVuaWNvZGUuCgpUaGUgYmlnZ2Vz
dCBwcm9ibGVtIHdpdGggKnByb3BlciogbWF0aCBVbmljb2RlIGFyZSB0aGUgIk1hdGhlbWF0aWNh
bApBbHBoYW51bWVyaWMgU3ltYm9scyIsIHdoaWNoIGFyZSBmb3VuZCBpbiB0aGUgMUQ0MDAuLjFE
N0ZGIHJhbmdlLCBub3QKaW4gdGhlIEJhc2ljIE11bHRpbGluZ3VhbCBQbGFuZS4gVGhlc2UgYXJl
IG5vdCBmb3VuZCBpbiBhbnkgZnJlZSBmb250LgpJIGFsc28gbm90aWNlZCB0aGF0IFB5dGhvbidz
IHN1cHBvcnQgZm9yIFVuaWNvZGUgb3V0c2lkZSB0aGUgQk1QIHBsYW5lCmlzIG5vdCB2ZXJ5IGdv
b2QuIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSB3b3JrcyBvbiBMaW51eCAoVWJ1bnR1IDYuMDYpLApi
dXQgZG9lc24ndCB3b3JrIG9uIFdpbmRvd3MgWFAgKDMyKToKCj4+PiBpbXBvcnQgdW5pY29kZWRh
dGEKPj4+IHVuaWNvZGVkYXRhLm5hbWUoVSdVXFUwMDAxZDQwMCcpClRyYWNlYmFjayAobW9zdCBy
ZWNlbnQgY2FsbCBsYXN0KToKICBGaWxlICI8c3RkaW4+IiwgbGluZSAxLCBpbiA/ClR5cGVFcnJv
cjogbmVlZCBhIHNpbmdsZSBVbmljb2RlIGNoYXJhY3RlciBhcyBwYXJhbWV0ZXIKClRoZSBvdXRw
dXQgc2hvdWxkIHNheToKTUFUSEVNQVRJQ0FMIEJPTEQgQ0FQSVRBTCBBCgpUaGUgIk1hdGhlbWF0
aWNhbCBBbHBoYW51bWVyaWMgU3ltYm9scyIgYmxvY2sgY29udGFpbnM6CiAqIE1hdGhlbWF0aWNh
bCBib2xkIGxldHRlcnMKICogTWF0aGVtYXRpY2FsIGl0YWxpYyBsZXR0ZXJzICh1c2VkIGZvciB2
YXJpYWJsZXMsIGRlZmF1bHQgZm9udCBpbgpUZVggbWF0aCBtb2RlKQogKiBNYXRoZW1hdGljYWwg
Ym9sZCBpdGFsaWMgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgc2NyaXB0IChjYWxsaWdyYXBoaWMp
IGxldHRlcnMKICogTWF0aGVtYXRpY2FsIGJvbGQgc2NyaXB0IGxldHRlcnMKICogTWF0aGVtYXRp
Y2FsIGZyYWt0dXIgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgZG91YmxlLXN0cnVjayBsZXR0ZXJz
CiAqIE1hdGhlbWF0aWNhbCBib2xkIGZyYWt0dXIgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgc2Fu
cy1zZXJpZiBsZXR0ZXJzCiAqIE1hdGhlbWF0aWNhbCBzYW5zLXNlcmlmIGJvbGQgbGV0dGVycwog
KiBNYXRoZW1hdGljYWwgc2Fucy1zZXJpZiBpdGFsaWMgbGV0dGVycwogKiBNYXRoZW1hdGljYWwg
c2Fucy1zZXJpZiBib2xkIGl0YWxpYyBsZXR0ZXJzCiAqIE1hdGhlbWF0aWNhbCBtb25vc3BhY2Ug
bGV0dGVycwogKiBEb3RsZXNzIHN5bWJvbHMKICogQm9sZCBHcmVlayBzeW1ib2xzCiAqIEFkZGl0
aW9uYWwgYm9sZCBHcmVlayBzeW1ib2xzCiAqIEl0YWxpYyBHcmVlayBzeW1ib2xzCiAqIEFkZGl0
aW9uYWwgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogQm9sZCBpdGFsaWMgR3JlZWsgc3ltYm9scwog
KiBBZGRpdGlvbmFsIGJvbGQgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogU2Fucy1zZXJpZiBib2xk
IEdyZWVrIHN5bWJvbHMKICogU2Fucy1zZXJpZiBib2xkIGl0YWxpYyBHcmVlayBzeW1ib2xzCiAq
IEFkZGl0aW9uYWwgc2Fucy1zZXJpZiBib2xkIEdyZWVrIHN5bWJvbHMKICogQWRkaXRpb25hbCBz
YW5zLXNlcmlmIGJvbGQgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogQm9sZCBkaWdpdHMKICogRG91
YmxlLXN0cnVjayBkaWdpdHMKICogU2Fucy1zZXJpZiBkaWdpdHMKICogU2Fucy1zZXJpZiBib2xk
IGRpZ2l0cwogKiBNb25vc3BhY2UgZGlnaXRzCgpUaGVzZSB3ZXJlIGFsbCBwdXQgaW4gdGhlIFVu
aWNvZGUgY2hhcmFjdGVyIHNldCBiZWNhdXNlIG9mIHRoZWlyCnNlbWFudGljIG1lYW5pbmdzIGlu
IG1hdGhlbWF0aWNzLCBhbHRob3VnaCBwcmFjdGljYWxseSBhbGwgYXJlIGp1c3QKZm9udCB2YXJp
YXRpb25zICg8Zm9udD4pLiBUaGUgcm9tYW4gbWF0aCBsZXR0ZXJzIChzZXJpZiwgbm9ybWFsLCB1
c2VkCmZvciBkaWdpdHMpIGRlZmF1bHQgdG8gdGhlICJCYXNpYyBMYXRpbiIgYmxvY2suCgpJdCBp
cyBpbnRlcmVzdGluZyB0byBub3RlIHRoYXQgdGhlICJNYXRoZW1hdGljYWwgQWxwaGFudW1lcmlj
IFN5bWJvbHMiCmJsb2NrIGRvZXNuJ3Qgc2VlbSB0byBiZSBzdXBwb3J0ZWQgYnksIGZvciBleGFt
cGxlLCBBcmlhbCBVbmljb2RlIE1TCihpdCBzdXBwb3J0cyBvbmx5IHRoZSBCTVApLgoKVGhpcyBp
c3N1ZSBjYW5ub3QgYmUgc3VjY2Vzc2Z1bGx5IHNvbHZlZCB1bnRpbCB0aGUgU1RJWCBmb250cyBj
b21lCm91dC4gSWYgdGhleSBwYWNrYWdlIHRoZW0gcmlnaHQgKGFuZCB0aGV5IG91Z2h0IHRvKSwg
d2UgY291bGQgaGF2ZSBhCnNpbmdsZSAudHRmIGZpbGUgZm9yIGFsbCB0aGUgZ2x5cGhzIG5lZWRl
ZCBmb3IgbWF0aHRleHQuIFVudGlsIHRoZW4sCmFueSBzb2x1dGlvbiB3aWxsIG5lZWQgc29tZSBz
b3J0IG9mIG1hcHBpbmcgYmV0d2VlbiB1bmljb2RlIGJsb2NrcwooY2hhcmFjdGVyIHJhbmdlcykg
YW5kIGZvbnRmaWxlcyAoYXQgbGVhc3QgZm9yIGl0YWxpYywgY2FsbGlncmFwaGljCmV0Yy4gZm9u
dHMpCgpQb3NzaWJsZSBlbmhhbmNlbWVudHMKPT09PT09PT09PT09PT09PT0KSSB0aGluayB0aGVy
ZSBzaG91bGQgYmUgYSB0aGluIFB5dGhvbiB3cmFwcGVyIGFyb3VuZCB0aGUgRnJlZVR5cGUyCkZU
MkZvbnQgY2xhc3MuIFRoZW4sIGZvciBleGFtcGxlLCBhbGwgdGhlIGNhY2hpbmcgY291bGQgYmUg
aGFuZGxlZCBieQp0aGF0IGNsYXNzLiBUaGlzIHdvdWxkIGFsbG93IG5vdCBvbmx5IGNhY2hpbmcg
Zm9yIG1hdGh0ZXh0LCBidXQgZXZlbgpmb3IgKnBsYWluIHRleHQqIGFuZCB3b3VsZCBjbGVhbiB1
cCBjb2RlLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgYWRkaW5nCm5ldyBmdW5jdGlvbmFsaXR5LCB3
aXRob3V0IG1lc3NpbmcgYXJvdW5kIHdpdGggQysrLCBhbmQgd2l0aG91dApicmVha2luZyBvbGQg
Y29kZS4KCk9uZSBjb3VsZCB0aGVuLCBmb3IgZXhhbXBsZSwgaGF2ZSBhIEZUMkZvbnQgY2xhc3Mg
bWV0aG9kCmdldF91bmljb2RlX2dseXBoIHRoYXQgd291bGQgcmV0dXJuIHRoZSBnbHlwaCBiYXNl
ZCBvbiBoaXMgdW5pY29kZQppbmRleCwgb3IgYmV0dGVyIHlldCwgdGhlIG5leHQgY29kZSB3b3Vs
ZCBiZSBlYXN5IGltcGxlbWVudGFibGU6CmdseXBocyA9IEZUMkZvbnQoJy9wYXRoL3RvL2ZvbnQn
KQpnbHlwaGEgPSBnbHlwaHNbJ2EnXQoKb3IgZXZlbjoKdGV4dF90b19yZW5kZXIgPSBnbHlwaHMu
dGV4dCgnU29tZSBsYW1lIHRleHQnKQoKb3Igc29tZXRoaW5nIHNpbWlsYXIuIEFnYWluLCB0aGlz
IHdvdWxkIG5vdCBicmVhayBvbGQgY29kZSBhbmQgd291bGQKZWFzZSB3cml0aW5nIG5ldyBjb2Rl
LiBIb3dldmVyLCBhcyBKb2huIG9uY2Ugc2FpZDoKClRoZSBmb250IGxpYnJhcnkgaXMgcHJvYmFi
bHkgYW4gU09DIHByb2plY3Qgb2YKaXQncyBvd24sIGJlY2F1c2Ugd2Ugd291bGQgbGlrZSB0byBz
ZXR0bGUgb24gb25lIGZyZWV0eXBlIGxpYnJhcnkgdGhhdApib3RoIG1hdHBsb3RsaWIgYW5kIGVu
dGhvdWdodC9jaGFjbyBjYW4gdXNlLiBIb3cgdG8gZGVhbCB3aXRoIHRoaXMKaXNzdWUgd2l0aG91
dCBiZWNvbWluZyBjb25zdW1lZCBieSBpdCB3aWxsIHJlcXVpcmUgc29tZSB0aG91Z2h0LgoKQ29u
Y2x1c2lvbgo9PT09PT09PQpKb2huLCB3aGF0IHNob3VsZCBJIGRvPyBQbGVhc2UgY29tbWVudC4K
CkkgdGhpbmsgdGhhdCB0aGUgYmVzdCBzb2x1dGlvbiByaWdodCBub3cgYXJlIHVuZm9ydHVuYXRl
bHkgdGhlIEJhS29NYQpmb250cy4gSWYgd2UgY291bGQgZ2V0IHRoZSBUeXBlMSBmb250cyB0byB3
b3JrIHRoZW4gSSBjb3VsZCBwcm9iYWJseQplYXNpbHkgaW5nZWdyYXRlIHRoZW0gaW50byB0aGUg
ZXhpc3RpbmcgbW9kZWwuIEkgY291bGQgYWxzbyB0cnkgdG8gZG8Kc29tZXRoaW5nIHdpdGggdGhl
IE9wZW4gU3ltYm9sIGZvbnRzLCBhbmQgdGhlIEZyZWVGb250ICh3aW5kb3dzIHVzZXJzCmNvdWxk
IGRvd2xvYWQgdGhlbSBzZXBwYXJhdGVseSkuCgpDaGVlcnMsCkVkaW4K

On 7/7/06, John Hunter <jdh...@ac...> wrote:
>
> We'd like to do a bugfix release for the next release of enthought
> python, which will include the latest mpl.  Apparently, there is a
> problem with 0.87.3 and numpy which has been fixed in svn.
>
> If there is anything we should wait on, let us know, otherwise we'll
> probably try to roll out 0.87.4 early next week.
>
> Thanks,
> JDH

http://cheeseshop.python.org/pypi/matplotlib/
http://sourceforge.net/project/showfiles.php?group_id=80706

===============================================================
2006-07-11 Released 0.87.4 at revision 2558

2006-07-07 Fixed a usetex bug with older versions of latex - DSD

2006-07-07 Add compatibility for NumPy 1.0 - TEO

2006-06-29 Added a Qt4Agg backend. Thank you James Amundson - DSD

2006-06-26 Fixed a usetex bug. On windows, usetex will prcess
           postscript output in the current directory rather than
           in a temp directory. This is due to the use of spaces
           and tildes in windows paths, which cause problems with
           latex. The subprocess module is no longer used. - DSD

2006-06-22 Various changes to bar(), barh(), and hist().
           Added 'edgecolor' keyword arg to bar() and barh().
           The x and y args in barh() have been renamed to width
           and bottom respectively, and their order has been swapped
           to maintain a (position, value) order ala matlab. left,
           height, width and bottom args can now all be scalars or
           sequences. barh() now defaults to edge alignment instead
           of center alignment. Added a keyword arg 'align' to bar(),
           barh() and hist() that controls between edge or center bar
           alignment. Fixed ignoring the rcParams['patch.facecolor']
           for bar color in bar() and barh(). Fixed ignoring the
           rcParams['lines.color'] for error bar color in bar()
           and barh(). Fixed a bug where patches would be cleared
           when error bars were plotted if rcParams['axes.hold']
           was False. - MAS

2006-06-22 Added support for numerix 2-D arrays as alternatives to
           a sequence of (x,y) tuples for specifying paths in
           collections, quiver, contour, pcolor, transforms.
           Fixed contour bug involving setting limits for
           color mapping.  Added numpy-style all() to numerix. - EF

2006-06-20 Added custom FigureClass hook to pylab interface - see
           examples/custom_figure_class.py

2006-06-16 Added colormaps from gist (gist_earth, gist_stern,
           gist_rainbow, gist_gray, gist_yarg, gist_heat, gist_ncar) - JW

2006-06-16 Added a pointer to parent in figure canvas so you can
           access the container with fig.canvas.manager.  Useful if
           you want to set the window title, eg in gtk
           fig.canvas.manager.window.set_title, though a GUI neutral
           method would be preferable JDH

2006-06-16 Fixed colorbar.py to handle indexed colors (i.e.,
           norm = no_norm()) by centering each colored region
           on its index. - EF

2006-06-15 Added scalex and scaley to Axes.autoscale_view to support
           selective autoscaling just the x or y axis, and supported
           these command in plot so you can say plot(something,
           scaley=False) and just the x axis will be autoscaled.
           Modified axvline and axhline to support this, so for
           example axvline will no longer autoscale the y axis. JDH

2006-06-13 Fix so numpy updates are backward compatible - TEO

2006-06-12 Updated numerix to handle numpy restructuring of
           oldnumeric - TEO

2006-06-12 Updated numerix.fft to handle numpy restructuring
           Added ImportError to numerix.linear_algebra for numpy -TEO

2006-06-11 Added quiverkey command to pylab and Axes, using
           QuiverKey class in quiver.py.  Changed pylab and Axes
           to use quiver2 if possible, but drop back to the
           newly-renamed quiver_classic if necessary.  Modified
           examples/quiver_demo.py to illustrate the new quiver
           and quiverkey.  Changed LineCollection implementation
           slightly to improve compatibility with PolyCollection. - EF

2006-06-11 Fixed a usetex bug for windows, running latex on files
           with spaces in their names or paths was failing - DSD

2006-06-09 Made additions to numerix, changes to quiver to make it
           work with all numeric flavors. - EF

2006-06-09 Added quiver2 function to pylab and method to axes,
           with implementation via a Quiver class in quiver.py.
           quiver2 will replace quiver before the next release;
           it is placed alongside it initially to facilitate
           testing and transition. See also
           examples/quiver2_demo.py. - EF

2006-06-08 Minor bug fix to make ticker.py draw proper minus signs
           with usetex - DSD

John Hunter wrote:

>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>>>>>            
>>>>>>
>
>    Eric> Correction: I did fix the first problem, and the second
>    Eric> problem is not at all what I thought.  Instead, the
>    Eric> examples/data/lena.jpg file in my svn mpl directory is
>    Eric> corrupted.  I have no idea why.  Looking directly at the
>
>This usually happens whenever Andrew commits -- don't know why
>(platform dependent new line problem, perhaps?)
>
>peds-pc311:~/mpl> svn log | grep astraw|head
>r2480 | astraw | 2006-06-15 06:33:07 -0500 (Thu, 15 Jun 2006) | 1 line
>r2430 | astraw | 2006-06-06 15:12:33 -0500 (Tue, 06 Jun 2006) | 1 line
>r2279 | astraw | 2006-04-10 10:35:31 -0500 (Mon, 10 Apr 2006) | 3
>lines
>r2180 | astraw | 2006-03-20 15:38:12 -0600 (Mon, 20 Mar 2006) | 1 line
>
>  
>
Hmm -- "usually happens"? I never noticed that. And I'm mystified as to
whether the output of svn log shows that. Let me know if I play any more
evil-line-ending tricks.

Anyhow, I think I fixed the corrupted file issue. I changed the deleted
the svn:eol-style property and added the set svn:mime-type property to
image/jpg and re-uploaded lena.jpg. I suspect this may have been a
victim of the cvs2svn switch, or perhaps I never checked it into cvs
properly.

Cheers!
Andrew

On 7/11/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> Correction: I did fix the first problem, and the second
>     Eric> problem is not at all what I thought.  Instead, the
>     Eric> examples/data/lena.jpg file in my svn mpl directory is
>     Eric> corrupted.  I have no idea why.  Looking directly at the
>
> This usually happens whenever Andrew commits -- don't know why
> (platform dependent new line problem, perhaps?)

Is that file tagged as binary in the repo?  If it is, it should be
impervious to OS-dependent EOL conventions...

Cheers,

f