matplotlib-devel Mailing List for matplotlib

This is (hopefully) a final rollup of what is (should be) a fairly
stable tree. Mainly I wanted to send a release notification out to
the larger python community (scipy/numpy/python-list) since I haven't
done that since 0.60 (July 2004). 
For the major releases, I tend to try and shy away from new features
preferring a stable src. But for you hardened, grizzled matplotlib
veterans, there are a few enticements nonetheless
 - pie charts and new example/pie_demo.py. See
 http://matplotlib.sf.net/screenshots.html#pie_demo
 - support for object picking - see examples/picker_demo.py. As
 people test this out and we settle on an interface, this will
 probably become part of the core, as will other keypress
 functionality for navigation, grid toogle, zoom toggle etc.
 - Fixed coords notification in wx toolbar 
 - key press and release event supported across backends -- see
 examples/keypress_demo.py
 - added Shadow patch class to provide a shadow effect for polygons,
 legends, pie charts -
 http://matplotlib.sf.net/screenshots.html#legend_demo
 - new examples/text_rotation.py demonstrates how text rotations and
 alignment work in matplotlib. 
Bug fixes
 - Fixed PS mathtext bug where color was not set
 - Fixed an agg text rotation alignment bug, fixed some text kwarg
 processing bugs
 - Refactored event handling - multiple connects and disconnects now
 work across backends. See examples/coords_demo.py, especially
 with test_disconnect
 - Fixed a tkagg interactive bug that caused segfaults in some
 conditions.
As usual, downloads at http://sourceforge.net/projects/matplotlib
JDH

GUI neutral event handling has been a thorn in my side, trying to deal
with flakiness in some GUIs that don't properly handle multiple
connects and disconnects (yes tk and wx, I'm lookin' at you), and so
it has been partially implemented and partially broken on these
backends.
When I went to add key press event handling, I confronted these same
issues again and this time tackled them head on.
Now the FigureCanvasBase does all the connection and disconnection
handling by keeping a dictionary of callbacks. The backends no longer
need to implement mpl_connect or mpl_disconnect, as this is handled
entirely by the base class. Neither do they need to know about
MPLEvent (which no longer exists). This class has been factored into
a base class Event and two derived classes MouseEvent and KeyEvent.
The attributes are the same so it will be transparent to the user.
All the backend has to do is call, for example
 FigureCanvasBase.button_release_event(self, x, y, self._button, self._key)
on every button release event and the base class will do the rest
(figure out data coords, whether you are over an axes, init the right
Event, and fire off the callbacks, handling multiple connects and
disconnects properly -- eg examples/coords_demo.py with and without
test_disconnect works on tk, wx and gtk.
The backend code is simpler too, and we now have GUI neutral key press
event handling too -- see examples/keypress_demo.py.
I ported these changes to WX, GTK and Tk and committed them. Gregory,
I still haven't gotten FLTK up and running, so I didn't try to port
these changes to FLTK, but I suspect it will be an easy for you. Give
it a whirl and let me know.
The backends need to call the FigureCanvasBase methods, with the args
as described in the docstrings of those methods: key_press_event,
button_press_event, button_release_event, motion_notify_event.
Now I feel better,
JDH

John Hunter wrote:
>>>>>>"David" == David Fraser <da...@sj...> writes:
>>>>>> 
>>>>>>
>
> David> This is fantastic, I hope it fixes the crashes I've been
> David> having which I finally seem to have traced down to
> David> matplotlib freeing images ... 
>
>Hi David,
>
>It probably won't fix it, because I didn't do anything that should
>effect memory handling, but we'll keep our fingers crossed. If you
>continue to experience problems and have any more information about
>the bug, pass it on.
> 
>
Actually it has seemed to have fixed it. I'm not going to go back and 
work out why though ... thanks for the update! Exactly when I needed it!
> David> One question though:
> David> FigureManagerBase's add_axes, add_subplot and
> David> set_current_axes methods have been removed (and this
> David> doesn't seem to be mentioned in API_CHANGES). What should I
> David> do to replace a call to add_axes?
>
>Sorry, I got lazy. I updated API_CHANGES on the web. I thought only
>the GUI backends were using add_subplot, set_current_axes, etc, and I
>ported the changes to all the GUIs. See my last post
>http://sourceforge.net/mailarchive/forum.php?thread_id=6207208&forum_id=36187
>for more information.
>
>Basically the figure class itself maintains the current axes - the
>motivation for the changes is in the post above. Call fig.add_axes,
>fig.add_subplot, fig.gca and fig.sca (set_current_axes).
>
>Hope this helps,
>JDH
> 
>
OK thanks, worked it out in the meantime but the list is slow :-)
David

David Fraser wrote:
> John Hunter wrote:
>
>> This is primarily a bug-fix release from 0.65, though a couple of
>> little features managed to sneak in
>> 
>>
> This is fantastic, I hope it fixes the crashes I've been having which 
> I finally seem to have traced down to matplotlib freeing images ...
> One question though: FigureManagerBase's add_axes, add_subplot and 
> set_current_axes methods have been removed (and this doesn't seem to 
> be mentioned in API_CHANGES). What should I do to replace a call to 
> add_axes?
Sorry, my stupid question, have now read the message on the list about this.
The answer is call figuremanager.canvas.figure.add_axes - but maybe this 
should be added to the API_CHANGES document
David

>>>>> "David" == David Fraser <da...@sj...> writes:
 David> This is fantastic, I hope it fixes the crashes I've been
 David> having which I finally seem to have traced down to
 David> matplotlib freeing images ... 
Hi David,
It probably won't fix it, because I didn't do anything that should
effect memory handling, but we'll keep our fingers crossed. If you
continue to experience problems and have any more information about
the bug, pass it on.
 David> One question though:
 David> FigureManagerBase's add_axes, add_subplot and
 David> set_current_axes methods have been removed (and this
 David> doesn't seem to be mentioned in API_CHANGES). What should I
 David> do to replace a call to add_axes?
Sorry, I got lazy. I updated API_CHANGES on the web. I thought only
the GUI backends were using add_subplot, set_current_axes, etc, and I
ported the changes to all the GUIs. See my last post
http://sourceforge.net/mailarchive/forum.php?thread_id=6207208&forum_id=36187
for more information.
Basically the figure class itself maintains the current axes - the
motivation for the changes is in the post above. Call fig.add_axes,
fig.add_subplot, fig.gca and fig.sca (set_current_axes).
Hope this helps,
JDH

John Hunter wrote:
>This is primarily a bug-fix release from 0.65, though a couple of
>little features managed to sneak in
> 
>
This is fantastic, I hope it fixes the crashes I've been having which I 
finally seem to have traced down to matplotlib freeing images ...
One question though: FigureManagerBase's add_axes, add_subplot and 
set_current_axes methods have been removed (and this doesn't seem to be 
mentioned in API_CHANGES). What should I do to replace a call to add_axes?
David

This is primarily a bug-fix release from 0.65, though a couple of
little features managed to sneak in
 - 4x image speedups for large images
 - figimage bug fixed
 - fixed some bugs which caused the colorbar not to update properly
 when changing colormap interactively
 - refactored axes management to support delaxes, which deletes, as
 opposed to clears, a specified axes. Default to current axes
 - tkagg's classic and new-fangled toolbars are now embeddable.
 - extended the new set/get introspection features to more classes
 - fixed some tkagg flakiness on win32 regarding unusual uses of show.
 - new cross backend animation idiom in examples/anim.py - use
 interactive mode rather than timers/idle handlers.
 - deferred some initializations in dates and colors modules for
 faster load times.
http://sourceforge.net/projects/matplotlib
Enjoy!
JDH 

> As my Christmas present to the backend maintainers, I ported these
> changes to WX, GTK, Tk and FLTK. I don't have FLTK on my system so
> Gregory please test. I have run the other backends through
> backend_driver.py and have done some interactive testing as well and
> everything looks good. But please update from CVS after giving the
> mirrors a few hours and test for yourself.
Hi John,
a quick interactive test and backend_driver both work for FltkAgg,
thanks for your Christmas present :-)
Merry Christmas and happy new year to all the list and matplotlib users,
Greg.

Fernando Perez wrote:
> hi all,
> 
> A few minor nits with mpl 0.65:
> 
> 1. I just tried to build an rpm for mpl via bdist_rpm, and it unfortunately
> fails. The problem is the extra -debuginfo rpm which gets generated in the
> process, which then causes the setup.py process to abort. It would be very
> nice to be able to use bdist_rpm to cleanly generate RPMs out of the sources,
> for handling installation via yum on multiple boxes.
OK, here's a quick and dirty fix I found. In distutils/command/bdist_rpm.py, 
around line 309, use the following:
 if not self.dry_run:
 if not self.binary_only:
 srpms = glob.glob(os.path.join(rpm_dir['SRPMS'], "*.rpm"))
 #assert len(srpms) == 1, \
 # "unexpected number of SRPM files found: %s" % srpms
 #self.move_file(srpms[0], self.dist_dir)
 map(lambda f:self.move_file(f,self.dist_dir),srpms)
 if not self.source_only:
 rpms = glob.glob(os.path.join(rpm_dir['RPMS'], "*/*.rpm"))
 #assert len(rpms) == 1, \
 # "unexpected number of RPM files found: %s" % rpms
 #self.move_file(rpms[0], self.dist_dir)
 map(lambda f:self.move_file(f,self.dist_dir),rpms)
I commented out the asserts which cause the operation to fail, and replaced 
them with a brute-force map call. I'll try to have some form of this change 
sent upstream to python-dev, b/c that stupid assert causes no end of grief for 
extension RPMs.
I guess this makes it a bit of a real Xmas gift :)
Cheers,
f

hi all,
A few minor nits with mpl 0.65:
1. I just tried to build an rpm for mpl via bdist_rpm, and it unfortunately
fails. The problem is the extra -debuginfo rpm which gets generated in the
process, which then causes the setup.py process to abort. It would be very
nice to be able to use bdist_rpm to cleanly generate RPMs out of the sources,
for handling installation via yum on multiple boxes.
2. I think there are some hardcoded paths in mpl which shouldn't. I installed
 it (after the rpm failure) with 'install --prefix=/usr/local', and the date
demos fail:
planck[examples]> python date_demo1.py
Could not find bitmap file "/usr/share/matplotlib/home.xpm"; dying
Note that:
planck[examples]> d /usr/local/share/matplotlib/home.xpm
-rw-r--r-- 1 root 5135 Jul 20 12:13 /usr/local/share/matplotlib/home.xpm
which is as it should, since I specified my prefix as /usr/local. The runtime
code should not assume that the base prefix is necessarily /usr, since this
can be changed at installation time by the user.
3. The dates stuff also has problems when running in non-english locales:
In [1]: run date_demo2.py
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most recent
call last)
/home/fperez/code/python/pylab/examples/date_demo2.py
 20
 21
---> 22 quotes = quotes_historical_yahoo('INTC', date1, date2)
 23 if not quotes:
 24 print 'Found no quotes'
/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in
quotes_historical_yahoo(ticker, date1, date2)
 61 if len(vals)!=7: continue
 62 datestr = vals[0]
---> 63 dt = datetime.date(*time.strptime(datestr, '%d-%b-%y')[:3])
 64 d = date2num(dt)
 65 open, high, low, close = [float(val) for val in vals[1:5]]
/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in
strptime(data_string, format)
 422 found = format_regex.match(data_string)
 423 if not found:
--> 424 raise ValueError("time data did not match format: data=%s
fmt=%s" %
 425 (data_string, format))
 426 if len(data_string) != found.end():
ValueError: time data did not match format: data=1-Dec-03 fmt=%d-%b-%y
WARNING: Failure executing file: <date_demo2.py>
In [3]: !echo $$LANG
de_DE.UTF-8
If I switch to the US locale, the code runs (until the crash listed in #2
because of the path problem).
Anyway, this is _my_ Christmas gift to matplotlib ;)
Cheers,
f

In thinking about Michel Sanner's problem of removing subplots, I
decided to make some changes in the way axes and subplot management
was done by the backends and the pylab interface. The problem was
that there was a chain of calls from the FigureManager for adding
subplots and axes to the Figure, and this was done so the
FigureManager could manage the current axes. The other reason it was
designed this way is the figure manager need to be notified whenever
the number of axes changed, so it could update the classic toolbar
menu.
The problem with this design is that every time I wanted to add a new
kwarg or some other feature to add_axes or add_subplot in the Figure,
these changes had to be mirrored in the FigureManager, sometimes
across backends which had concrete implementations, which proved to be
a pain. And when I wanted to think about deleting axes, I had to
worry about the FigureManager's information and the figure's
information, which was a bad design.
In its place, I added the management of the current axes to the Figure
class itself, and used an observer pattern so the backend
FigureManager could get notification when the number of axes changed.
So FigureManager add_subplot and add_axes methods no longer exist.
Note the Figure doesn't *do* anything with the current axes
information, it merely manages it.
As my Christmas present to the backend maintainers, I ported these
changes to WX, GTK, Tk and FLTK. I don't have FLTK on my system so
Gregory please test. I have run the other backends through
backend_driver.py and have done some interactive testing as well and
everything looks good. But please update from CVS after giving the
mirrors a few hours and test for yourself.
Ted, please make sure your QT implementer is advised of these changes.
There is also a new method Figure.delaxes and a pylab interface
function delaxes to remove an axes from the Figure. This is different
from merely clearing an axes with cla, and the Figure updates the
current axes after a call to delaxes using an axes stack so the
previously current axes becomes current after a deletion. Eg,
 from pylab import *
 ax1 = subplot(211)
 plot([9,10,11])
 ylabel('y1')
 ax2 = subplot(212)
 scatter(rand(10), rand(10))
 ylabel('y2')
 subplot(211) # make 211 current
 title('this is a title', color='r')
 grid()
 delaxes(ax1) # now 212 is current again
 grid()
Thanks,
JDH

Here's something I find surprising (and disconcerting):
astraw@flygate:~$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> min(1,2)
1
 >>> from pylab import *
 >>> min(1,2)
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File 
"/usr/lib/python2.3/site-packages/numarray/linear_algebra/mlab.py", 
line 149, in min
 return minimum.reduce(m,axis)
ValueError: Empty array in a ufunc that has no identity value.
So, it seems that the "min" function is overridden. Digging deeper,
 >>> min.__module__
'numarray.linear_algebra.mlab'
OK, I see what's going on here: in an effort to achieve maximum matlab 
compatibility, pylab imports everything (or at least min) from 
numarray.linear_algebra.mlab. The trouble with this is that a simple 
"from pylab import *" will break a script that uses min() on scalars. 
While numarray may have very good reasons for overriding builtins 
(although I admit that I cannot see what), I think causing normal 
Python scripts to break by simply importing pylab into their namespace 
is not the way to achieve total world domination. :)
This may be a numarray.linear_algebra.mlab bug/issue and I should go to 
their mailing list. (Although here is probably as good a place to 
reach them :). But, even if the good numarray folks did it this way 
for a reason (I'd love to know, but I should hunt on their FAQ before 
asking), I suggest than pylab seek to not (incompatibly) override 
builtins.
Again, "from pylab import *" is our plan for total world domination, 
and I suggest we not break pure Python scripts.
The general problem does not appear serious:
 >>> from pylab import *
 >>>
 >>> for key in globals().keys():
... if key in dir(__builtins__):
... print "'%s' was overridden."%key
...
'round' was overridden.
'sum' was overridden.
'abs' was overridden.
'max' was overridden.
'min' was overridden.
'__doc__' was overridden.
'__name__' was overridden.
Cursory checks of the above functions indicate all except min(), max(), 
and round() are compatible with normal (non-exception raising) Python 
use. Even round() is apparently deprecated by numarray to around().
So, basically, I think we're just talking about min() and max().
What do folks think?

>>>>> "Jack" == Jack Diederich <jac...@ja...> writes:
 Jack> Hi, I just subscribed to the list and have been looking at
 Jack> the source. I wrote a python graphing library so lots of
 Jack> the internals are familair (how many ways can you draw a
 Jack> line?) but spending a couple hours browsing the code I can't
 Jack> get a handle on how layout is done. Are things generally at
 Jack> fixed positions? Are there some things I can
 Jack> subclass/decorate to get a different look or feel?
Yes, things are placed in fixed positions. Fixed here can mean
relative to something else, as in 20% from the left side of the axes,
but not free in the sense of a layout engine that tries to find
optimal placement.
For example, you can place axes with
 axes([left, bottom, width, height]) 
and these are expressed in fractions of the figure width and height.
Eg, http://matplotlib.sourceforge.net/screenshots.html#axes_demo. Or
you can place a rectangle in relative axes coords (0,0) bottom left,
(1,1) top right with a custom transform
 Rectangle( xy=(0.25, 0.5), width=0.1, height=0.2,
 transform=ax.transAxes)
There has been a lot of clamoring for a layout engine, particularly
because when you have a number of subplots, the text labels from one
axes can overlap another as discussed here -
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP . In order to
incorporate a layout engine, you would need at a minimum to subclass
Figure and Axes. Most of the scene objects (matplotlib.artist.Artist)
can return their bounding box in window extent, and you could use this
information to help with layout. The transforms module has a helper
function bbox_all which takes a sequence of bounding boxes
(transform.Bbox instances) and returns the box that bounds them all --
very useful when doing layout. Basically, the Figure would want to
inspect it's axes and the axes in turn would inspect the bounding
boxes of the objects in contains.
The only catch is that in the current implementation, text instances
do not know their window extent until drawing time. This is because
text sizes are backend dependent, and the class that knows how to size
text is the backend Renderer, which isn't known to the objects until
the call to Artist.draw(renderer). This has proved to be a pain in
the ass since in some classes (eg legend, ticks, tables and text
itself) which need to do some layout involving text, the layout is
deferred until drawing time and then the information is sometimes
cached for efficiency. Typically this leads to hairy, suboptimal, and
hard-to-maintain code, cf Legend._update_positions and
Text._get_layout.
One potential way out of this dilemma is to use the ft2font module
(matplotlib's freetype2 wrapper) to get the layout information
whenever you want it. matplotlib's core backend agg uses this anyhow,
and postscript embeds freetype2 fonts and so uses it too. It remains
to be seen how well this strategy would work on the SVG and Cairo
backends, which are the only other two renderers are actively
supported and used, as far as I know. I know Steve has taken some
pains to get Cairo text sizing similar to Aggs/GTKs, so it may serve
as a good enough approximation for layout purposes for cairo as well.
We've been trying to push GD users -> Agg, and users who use native
GTK/WX drawing to GTKAgg/WXAgg, because this simplifies maintenance.
 Jack> I had a longstanding misimpression that matplotlib was a
 Jack> wrapper around matlab or I might have abandoned my custom
You're not the first to have this misperception. I wonder how we can
combat it. Perhaps renaming the main interface pylab will help. Or a
blinking box on the homepage maybe - "matplotlib does not require
matlab! That's the whole point!!'" :-)
 Jack> work and just thrown in here. If I can get graphs that look
 Jack> like this[1] I'll do just that.
We'd love to have you on board - then we'd be collaborating on two
projects :-)
 Jack> Sorry for the vague questions, but I'll try to recompense by
 Jack> porting my PIL and ming backends over Christmas. The
 Jack> unmodified backends are stupid similar to matplotlib (again,
 Jack> there aren't too many ways to spell 'line')
Right, the backends are dumb as bricks by design, because this lowers
the barrier of entry in writing a new backend. Actually, they're too
dumb currently, because the frontend handles the transformation to
display coordinates, which isn't optimal for backends that have
transformations built in (eg PS, SVG) and leads to some problems with
subpixel antialiasing in agg. Fixing this is on the list of things to
do.
 Jack> Ignore the "shape_*" methods, they just return a handle to
 Jack> paintable objects instead of doing the paint right away
 Jack> (required for doing hovers and sprites in ming/Flash).
As I mentioned to you earlier, I think the hover capabilities of
ming/Flash would be very appealing to webapp developers. Actually, I
think these are great for all domains, because they let you pack so
much information into a figure. Could this be embedded in a GUI,
bychance? 
I've been meaning to make some alterations in the frontend to support
clickable elements, eg in SVG, and this wouldn't be hard. The same
framework could be used for tagging hover elements. If you want to
take the lead here, by all means. Otherwise, when you get to this
point let me know and I can work with you on it.
 Jack> [1] I only need a few kinds of graphs but they are for
 Jack> marketing folks instead of tech folks so purtier is better.
 Jack> I put up some samples of our current output here (png &
 Jack> Flash) http://jackdied.com/jackdied/graph_sample.html
Everything except the 3D bar look is already supported. We have major
and minor ticking, solid date support, legends, bar and line charts.
I'm personally not too interested in 3D bars because I don't think the
3D effect adds any information and arguably reduces it. I would not
oppose a patch, though. It would be fairly trivial to write, I
suspect.
See examples/major_minor_demo*.py, examples/date_demo*.py
examples/barchart_demo.py and examples/legend_demo*.py in the src
distro.
A few brief notes:
 - you can set the figure background color with the figure command
 and customize the default in the rc file
 - you can customize the default grid style (eg a solid gray line)
 using the rc file, the rc command, or directly setting the line
 properties on the result of, eg, ax.get_xgridlines()
 
 lines = ax.get_xgridlines() + ax.get_ygridlines()
 set(lines, linestyle='-', color='lightslategray', linewidth=1)
 
 - You have a "bar" and a "plot" overlayed. Just make sure hold is
 set to True so that subsequent plots don't overwrite old plots.
 You can set the default state in rc, toggle it with the "hold
 command" or pass hold as a kwarg on a given plot command to
 temporarily override the hold state
 - To offset the major ticks ('Nov', 'Dec') below the minor ticks,
 you may want to simply prepend them with a newline ('\nNov',
 '\nDec'). You'll want to use custom date tick formatters as
 illustrated in the date demo files referenced above. There are a
 number of other ways to control the vertical offset (see also the
 verticalalignment of the text instances) but the newline trick may
 be enough to get them into the position you want.
 - The legend doesn't have a shadow feature built in, though you
 could add one trivially and I would be happy to accept a patch. 
 This could be a general feature of patches, actually.
 JDH

Hi, I just subscribed to the list and have been looking at the source.
I wrote a python graphing library so lots of the internals are familair
(how many ways can you draw a line?) but spending a couple hours browsing
the code I can't get a handle on how layout is done. Are things generally
at fixed positions? Are there some things I can subclass/decorate to get
a different look or feel?
I had a longstanding misimpression that matplotlib was a wrapper around
matlab or I might have abandoned my custom work and just thrown in here.
If I can get graphs that look like this[1] I'll do just that.
Sorry for the vague questions, but I'll try to recompense by porting my PIL 
and ming backends over Christmas. The unmodified backends are stupid similar
to matplotlib (again, there aren't too many ways to spell 'line')
Python 2.3.4 (#2, Dec 3 2004, 13:53:17) 
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Graph
>>> filter(lambda x:'__' not in x, dir(Graph.mingDraw))
['circle', 'clip', 'color', 'color_from_tup', 'line', 'pieslice', 'polygon', 
 'rectangle', 'shape_circle', 'shape_line', 'shape_pieslice', 
 'shape_rectangle', 'text', 'tup_from_color', 'write']
Ignore the "shape_*" methods, they just return a handle to paintable objects
instead of doing the paint right away (required for doing hovers and sprites
in ming/Flash).
-Jack
[1] I only need a few kinds of graphs but they are for marketing folks
 instead of tech folks so purtier is better. I put up some samples of
 our current output here (png & Flash)
 http://jackdied.com/jackdied/graph_sample.html

These notes, with links, can be read at
http://matplotlib.sf.net/whats_new.html.
 - matlab namespace renamed pylab - see
 http://matplotlib.sf.net/matplotlib_to_pylab.py for details on
 conversion. ipython pylab users should grab version 0.6.6. You
 can import the matlab interface (now known as pylab interface) with
 from pylab import blah # OK
 from matplotlib.pylab import blah # OK
 from matplotlib.matlab import blah # Deprecated
 - contouring with the contour function!! Thanks to Nadia Dencheva.
 See examples/contour_demo.py
 - matlab compatible set and get introspection to determine settable
 properties and their values. See examples/set_and_get.py. Sample
 usage
 >>> lines = plot([1,2,3]) 
 >>> set(lines)
 alpha: float
 antialiased or aa: [True | False]
 ...snip lots more...
 >>> get(lines)
 alpha = 1.0
 antialiased or aa = True
 ...snip lots more...
 - Added many new matlab compatible colormaps - autumn bone cool
 copper flag gray hot hsv jet pink prism spring summer winter -
 Thanks Perry!
 - zorder to artists to control drawing order of lines, patches and
 text in axes. See examples/zorder_demo.py 
 - mathtext in cairo backend. Also, printing now works to file
 object. Thanks Steve Chaplin.
 - printing in WX - Matthew Newville contributed a print button and
 preview for the wx backends. He also, who graciously volunteered
 to be the new wx backend maintainer.
 - matlab interface functions connect and disconnect replace
 mpl_connect and mpl_disconnect for event handling
 - Pass hold=True|False to any plotting command to override the
 current hold setting. The original hold setting will be restored
 at the end of the plot function
 - all text instances now have a bbox property which is a dict of
 Rectangle properties. If set, the text instance will display in a
 rectanglular bounding box. Example usage
 
 title('hi mom', bbox={'facecolor':'r', 'alpha':0.5})
 - legend properties now exposed as kwargs. See help(legend)
 - ishold to inspect the hold state
 - new plotting functions spy, spy2 for matrix sparsity visualization
 - pylab interface functions rgrids and thetagrids for customizing
 the grid locations and labels for polar plots - see
 examples/polar_demo.py.
 - add ion, ioff and isinteractive to pylab interface for control of
 interactive mode. See updated discussion at
 http://matplotlib.sf.net/interactive.html
Bugs fixed - 
 - Fixed colorbar bug with scatter - JDH
 - SVG clipping problem - Thanks Norm Peterson
 - numerous small legend bugs fixed
 - zoom to rect works with reversed axis limits - thanks Gregory
 - fontsizing problem fixes, ps plots correctly sized, landscape
 support for ps output
 - smaller, leaner, meaner PS output - Thanks Jochen
 - make the Gtk backends build without an X-server connection -
 Thanks Jochen
 
Downloads at http://matplotlib.sf.net
JDH

Hello,
I will be on Christmas vacation until January 6.
Unfortunately I won't have time to fix the square-root
positioning problem for the PostScript backend before
I leave.
All the best and a merry Christmas,
Jochen
--=20
http://seehuhn.de/

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Out of these timezones in dates.py UTC = timezone('UTC')
 Steve> Eastern = timezone('US/Eastern') Central =
 Steve> timezone('US/Central') Mountain = timezone('US/Mountain')
 Steve> Pacific = timezone('US/Pacific') London =
 Steve> timezone('Europe/London') Paris = timezone('Europe/Paris')
 Steve> Berlin = timezone('Europe/Berlin') Moscow =
 Steve> timezone('Europe/Moscow')
 Steve> As far as I can see the only timezones actually used are
 Steve> UTC - as a function default value, and Pacific - used in
 Steve> __main__ Is it OK to remove all the unused ones, or is
 Steve> there something that relies on them?
Well, I provided these for convenience for people to import from the
dates module. It never occurred to me that simply instantiating 7
objects would carry such a performance hit. However, it doesn't
appear that I documented this anywhere, so it should be safe to remove
them - just make a note in the API_CHANGES file that they are gone and
I'll mention it in the release notes.
JDH

On Sun, 2004年12月12日 at 15:09 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> I suggest - for optional modules (like dates), only import
> Steve> them when they are required (when the plot actually has a
> Steve> date) - for all modules try to minimise the amount of code
> Steve> that will execute upon import, especially function calls.
> 
> Steve> What do you think?
> 
> Sounds great. Thanks for tracking this one down. A 10% speedup is
> well worth it. It sounds like the dates module should also cache the
> timezone info. Do you want to take the lead on this one? 
> 
> JDH
Out of these timezones in dates.py
UTC = timezone('UTC')
Eastern = timezone('US/Eastern')
Central = timezone('US/Central')
Mountain = timezone('US/Mountain')
Pacific = timezone('US/Pacific')
London = timezone('Europe/London')
Paris = timezone('Europe/Paris')
Berlin = timezone('Europe/Berlin')
Moscow = timezone('Europe/Moscow')
As far as I can see the only timezones actually used are
UTC - as a function default value, and Pacific - used in __main__
Is it OK to remove all the unused ones, or is there something that
relies on them?
Steve

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> Doing the commands: ------------------------------ from
 Norbert> matplotlib.matlab import * plot((1,2),(3,4))
 Norbert> figtext(0.5,0.5,"$\sqrt 2$") savefig("tryout.eps")
 Norbert> ------------------------------
 Norbert> diplays the sqrt sign shifted upwards against the regular
 Norbert> text.
Looks like the dreaded cmex bug. Paul, any ideas?
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I suggest - for optional modules (like dates), only import
 Steve> them when they are required (when the plot actually has a
 Steve> date) - for all modules try to minimise the amount of code
 Steve> that will execute upon import, especially function calls.
 Steve> What do you think?
Sounds great. Thanks for tracking this one down. A 10% speedup is
well worth it. It sounds like the dates module should also cache the
timezone info. Do you want to take the lead on this one? 
JDH

I've been doing some profiling using
'hotshotmain.py simple_plot.py -dAgg >/tmp/hs-out 2>&1'
(with the Tools/scripts/hotshotmain.py script from the Python src
distribution)
I looked at the output and noticed that the pytz module takes up a fair
amount of the time. Which is a bit unexpected for simple_plot.py which
does not have any dates!
I commented out the 'dates' imports in pylab.py and axes.py and
performance increased 13%. It seemed strange for an import to have such
a large effect, but when I looked at dates.py I saw that it executes
code - it calls timezone() 9 times - a function which does further
imports which read in a lot of data.
If I restore the 'dates' imports and just comment out the 9 timezone()
calls in dates.py the speedup is 11% and it saves around 3,000 function
calls!
I suggest
- for optional modules (like dates), only import them when they are
required (when the plot actually has a date)
- for all modules try to minimise the amount of code that will execute
upon import, especially function calls.
What do you think?
Steve

>>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 Jody> The real reason that I am working on Cairo and matplotlib is
 Jody> that I want a portable way to display output from ATT's
 Jody> graphviz. From my quick look through matplotlib's code, it
 Jody> looks like this may be hard to do. So, if I continue this
 Jody> project, I'll also be asking how to render ploygons,
 Jody> ellipses, and text. Do you think that matplotlib is a good
 Jody> fit given my requirements?
Without commenting on goodness of fit, I'll add that matplotlib has
fundamental elements for polygons (matplotlib.patches.Polygon) and
text (matplotlib.text.Text) and it would be straightforward to add a
dedicated ellipse class (currently we just use polygons for ellipses)
and Ted also has an interest in creating an ellipse class for scale
free renderering, eg in the postscript backend.
JDH

Jody,
I have someone working on a Qt front end (using Agg for rendering). He's 
only able to put in roughly 1 day/week and with the holidays coming up I'm 
not sure when it's going to be finished. We're looking in to the 
possibility of being able to contribute this back to matplotlib (if John 
wants it) but there are legal issues on my end that need to get resolved 
before I'll know if it's possible.
FYI: If you want to render the output from graphviz, have you looked at 
dot? The C/C++ tool doxygen uses graphviz/dot to render inheritance 
diagrams and place them in web pages (with click-able boxes no less).
Ted
At 11:15 AM 12/9/2004, Jody Winston wrote:
>John Hunter writes:
> > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
> >
> > Jody> Any pointers on either finding a Qt backend or writing one?
> > Jody> Thanks,
> >
> > Hi Jody,
> >
> > Sorry for the delay in getting back to you - I've been out of town for
> > a week.
> >
> > There have been several people who have expressed interest in A QT
> > backend - most recently Ted Drain at the JPL. Perhaps you two could
> > coordinate your efforts?
>
>I'd be happy to work with Ted.
>
> > The first place to start is in the file
> > matplotlib/backends/backend_template.py, which serves as a template
> > for backend writers and gives some instructions. I would follow the
> > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
> > WXAgg, which use Agg to render the image and place it in the GUI
> > canvas. This is a lot less work and you automiatically get the latest
> > matplotlib feature set for free. The basic idea is to use a GUI
> > independent image library that can then be reused across GUIs.
> >
> > The backends have to implement concrete versions of several interface
> > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
> > FigureManagerBase, NavigationToolbar2. If you opt to use Agg (or
> > Cairo) to do the drawing for you, you can leave out RendererBase and
> > GraphicsContextBase, which are the two that require the most work.
>
>I've also built a SWIG interface for Cairo so that I can embed it in a
>Qt application.
>
>The real reason that I am working on Cairo and matplotlib is that I
>want a portable way to display output from ATT's graphviz. From my
>quick look through matplotlib's code, it looks like this may be hard
>to do. So, if I continue this project, I'll also be asking how to
>render ploygons, ellipses, and text. Do you think that matplotlib is
>a good fit given my requirements?
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On Thu, 2004年12月09日 at 13:15 -0600, Jody Winston wrote:
> I've also built a SWIG interface for Cairo so that I can embed it in a
> Qt application.
Matplotlib already supports Cairo rendering - it uses the Python Cairo
bindings PyCairo. For Qt to work with PyCairo I think you would just
need to write one function that connects an xlib target surface to Qt,
and then you would get all the matplotlib Cairo rendering done for free.
Steve

John Hunter writes:
 > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 > 
 > Jody> Any pointers on either finding a Qt backend or writing one?
 > Jody> Thanks,
 > 
 > Hi Jody,
 > 
 > Sorry for the delay in getting back to you - I've been out of town for
 > a week.
 > 
 > There have been several people who have expressed interest in A QT
 > backend - most recently Ted Drain at the JPL. Perhaps you two could
 > coordinate your efforts?
I'd be happy to work with Ted.
 > The first place to start is in the file
 > matplotlib/backends/backend_template.py, which serves as a template
 > for backend writers and gives some instructions. I would follow the
 > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
 > WXAgg, which use Agg to render the image and place it in the GUI
 > canvas. This is a lot less work and you automiatically get the latest
 > matplotlib feature set for free. The basic idea is to use a GUI
 > independent image library that can then be reused across GUIs. 
 > 
 > The backends have to implement concrete versions of several interface
 > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
 > FigureManagerBase, NavigationToolbar2. If you opt to use Agg (or
 > Cairo) to do the drawing for you, you can leave out RendererBase and
 > GraphicsContextBase, which are the two that require the most work.
I've also built a SWIG interface for Cairo so that I can embed it in a
Qt application.
The real reason that I am working on Cairo and matplotlib is that I
want a portable way to display output from ATT's graphviz. From my
quick look through matplotlib's code, it looks like this may be hard
to do. So, if I continue this project, I'll also be asking how to
render ploygons, ellipses, and text. Do you think that matplotlib is
a good fit given my requirements?