matplotlib-devel Mailing List for matplotlib (Page 13)

On Monday 02 June 2008 09:12:45 Michael Droettboom wrote:
> John Hunter wrote:
> > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <dar...@co...> 
wrote:
> >> I'll be working on converting docstrings to rest this weekend. Should
> >> any of this be done on the branch? Or should we just focus on the trunk?
> >
> > As far as I am concerned, the documentation effort is for the trunk.
> > The only reason to do them on the branch too is to make merges of
> > other code changes easier, which may be a compelling reason. If the
> > docstrings get far out of whack, it may make merging other changes
> > very painful. But at the same time, I don't want the burden of
> > trying to keep the two in sync stopping you from getting the work done
> > that you need to do. Maybe you can try it and see how hard it is, and
> > if proves to be too much of an impediment, just concentrate on the
> > trunk. Michael, any advice here?
>
> I was away on the weekend, so just getting back. Darren: you rock. The
> documentation is looking great!
I agree, the documentation is coming along nicely. But I don't think I should 
be singled out for credit, there's lots of good stuff appearing that I haven't 
had anything to do with.

On Monday 02 June 2008 08:33:55 Michael Droettboom wrote:
> Darren Dale wrote:
> > On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
> >> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
> >>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fpe...@gm...>
> >
> > I tracked this down by checking the contents of the generated
> > build/latex/Matplotlib.tex, line 954. It is from the following code from
> >
> > mathtext.rst:
> >> When using the STIX fonts, you also have the choice of:
> >>
> >> ================ =================================
> >> Command Result
> >> ================ =================================
> >> ``\mathbb`` :math:`\mathbb{Blackboard}`
> >> ``\mathcircled`` :math:`\mathcircled{Circled}`
> >> ``\mathfrak`` :math:`\mathfrak{Fraktur}`
> >> ``\mathsf`` :math:`\mathsf{sans-serif}`
> >> ================ =================================
> >
> > I'm not sure this is being properly rendered in the HTML output for me,
> > either. Mike, are you able to compile this into a pdf on your machine,
> > and if so, would you tell us how to configure STIX support? I commented
> > this block out in svn for now.
>
> Sorry about that. It requires the amssymb and/or amsmath LaTeX packages
> to render correctly. Perhaps it is better to not require the LaTeX
> installation to have anything special though. I think the best course
> of action is to just include pre-generated images in the documentation
> source for this. I'll go ahead and do that.
I added doc/static_figs to hold scripts that require optional dependencies to 
generate images for the docs. I would like to be able to keep track of how the 
images are generated, so if we lose one we know how to recreate it. I added 
two scripts (softlinks actually) a README and a make.py to that directory. 
make.py saves the images to doc/_static.

Eric Firing wrote:
> Ryan May wrote:
> 
>> Eric Firing wrote:
>> 
>>> rcsetup can't get it from backends/__init__.py because that would set 
>>> a backend selection in stone. But backends/__init__.py can get it 
>>> from rcsetup, and I am in the process of making that change on the 
>>> trunk. This duplication had annoyed me earlier, but I didn't do 
>>> anything about it then. Thanks for the prompt.
>>> 
>> Good to know. If you can't get to it, let me know and I'll take a stab.
>> 
>
> It's done now.
>
> 
>>> Are you actually looking into adding a new backend?
>>> 
>> Yeah. I'm finally getting back around to the OpenGL backend I've been 
>> kicking around for awhile now, based (right now) on Gtk. gtkglext 
>> (which has python bindings) will let you render to a pixmap, so that 
>> should make it easy to integrate into the current matplotlib way of 
>> doing things. If things go well, I should have more on this after awhile.
>> 
>
> Is the motivation 3D plotting?
> 
I am all ears.... ;)
JCT
> Eric
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Ryan May wrote:
> Eric Firing wrote:
>> rcsetup can't get it from backends/__init__.py because that would set 
>> a backend selection in stone. But backends/__init__.py can get it 
>> from rcsetup, and I am in the process of making that change on the 
>> trunk. This duplication had annoyed me earlier, but I didn't do 
>> anything about it then. Thanks for the prompt.
> 
> Good to know. If you can't get to it, let me know and I'll take a stab.
It's done now.
> 
>> Are you actually looking into adding a new backend?
> 
> Yeah. I'm finally getting back around to the OpenGL backend I've been 
> kicking around for awhile now, based (right now) on Gtk. gtkglext 
> (which has python bindings) will let you render to a pixmap, so that 
> should make it easy to integrate into the current matplotlib way of 
> doing things. If things go well, I should have more on this after awhile.
Is the motivation 3D plotting?
Eric

Eric Firing wrote:
> rcsetup can't get it from backends/__init__.py because that would set a 
> backend selection in stone. But backends/__init__.py can get it from 
> rcsetup, and I am in the process of making that change on the trunk. 
> This duplication had annoyed me earlier, but I didn't do anything about 
> it then. Thanks for the prompt.
Good to know. If you can't get to it, let me know and I'll take a stab.
> Are you actually looking into adding a new backend?
Yeah. I'm finally getting back around to the OpenGL backend I've been 
kicking around for awhile now, based (right now) on Gtk. gtkglext 
(which has python bindings) will let you render to a pixmap, so that 
should make it easy to integrate into the current matplotlib way of 
doing things. If things go well, I should have more on this after awhile.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Hi,
> 
> Is there any reason that adding a backend requires modifying both 
> rcsetup.py and the __init__.py in the backends subdirectory? Couldn't 
> rcsetup.py fetch the list from the __init__.py (or vice-versa)?
> 
> Thanks,
> 
> Ryan
> 
Ryan,
rcsetup can't get it from backends/__init__.py because that would set a 
backend selection in stone. But backends/__init__.py can get it from 
rcsetup, and I am in the process of making that change on the trunk. 
This duplication had annoyed me earlier, but I didn't do anything about 
it then. Thanks for the prompt.
Are you actually looking into adding a new backend?
Eric

Hi,
Is there any reason that adding a backend requires modifying both 
rcsetup.py and the __init__.py in the backends subdirectory? Couldn't 
rcsetup.py fetch the list from the __init__.py (or vice-versa)?
Thanks,
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi all,
I have some trouble with matplotlib's svn version.
Any pointer would be appreciated.
Thanks in advance
 Nils
/usr/bin/python -i nlp_3.py --verbose-helpful
$HOME=/home/nwagner
matplotlib data path 
/usr/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/matplotlibrc
matplotlib version 0.98.0
verbose.level helpful
interactive is False
units is False
platform is linux2
CONFIGDIR=/home/nwagner/.matplotlib
Using fontManager instance from 
/home/nwagner/.matplotlib/fontManager.cache
numerix numpy 1.2.0.dev5257
backend WXAgg version 2.5.3.1
starting solver ipopt (license: CPL) with problem nlp3
[PyIPOPT] Ipopt will use Hessian approximation.
[PyIPOPT] nele_hess is 0
iter objFunVal log10(maxResidual)
 0 -1.640e+02 0.81
Traceback (most recent call last):
 File "nlp_3.py", line 65, in ?
 r = p.solve(solver)
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
line 236, in solve
 return runProbSolver(self, solvers, *args, **kwargs)
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
line 219, in runProbSolver
 solver(p)
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/solvers/CoinOr/ipopt_oo.py", 
line 70, in __solver__
 p.iterfcn(p.x0)
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
line 57, in <lambda>
 self.iterfcn = lambda *args: ooIter(self, *args)# 
this parameter is only for OpenOpt developers, not common 
users
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooIter.py", 
line 78, in ooIter
 for df in p.graphics.drawFuncs: df(p)
 File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooGraphics.py", 
line 127, in oodraw
 if self.nSubPlots>1: pylab.subplot(self.nSubPlots, 1, 
1)
 File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 519, in subplot
 fig = gcf()
 File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 210, in gcf
 return figure()
 File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 195, in figure
 FigureClass=FigureClass,
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
line 119, in new_figure_manager
 frame = FigureFrameWxAgg(num, fig)
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1237, in __init__
 self.canvas.SetInitialSize(wx.Size(fig.bbox.width, 
fig.bbox.height))
AttributeError: 'FigureCanvasWxAgg' object has no 
attribute 'SetInitialSize'

> what do you mean by "range" parameter. What should this parameter actually 
> do ?
>
Actually just pass it along to numpy.histogram(). I guess it just ignores 
all data outside the range.
Cheers,
Olle

Stan West wrote:
> I've not studied or used the CallbackRegistry, so I've got nothing to add on
> that front. However, may I submit the attached work-around for Axes.cla?
> Instead of offsetting the title using Affine2D().translate( ... figure.dpi
> ... ), it uses ScaledTranslation( ... figure.dpi_scale_trans ...). This
> way, it seems to require no connection to the dpi_changed event (thereby
> sidestepping the callback accumulation). Also, it constructs
> titleOffsetTrans similarly to get_xaxis_text1_transform and its relatives,
> and it reduces the hard-coded 5-point offset from three occurences to one,
> which helps any future conversion to an rcParam.
> 
I think that's a great solution. I actually thought of it right after 
writing the last e-mail, but got onto other things. It's nice to see 
that someone else has picked up on the new transformations infrastructure.
> I verified that the old and new code produce the same transformation matrix.
> However, when I tried to retrieve the title's transformation, I received a
> rather long traceback. It can be reproduced with
>
> import matplotlib.transforms as mtransforms
> mtransforms.ScaledTranslation(0, 0, mtransforms.IdentityTransform())
>
> under 0.98.0. Now, how far have we deviated from the subject line? :-)
> 
You just mean when you try to print the transformation out, right? 
There is a missing comma in the ScaledTranslation.__repr__:
 def __repr__(self):
 return "ScaledTranslation(%s)" % (self._t,)
I've fixed both of these things on the trunk. Thanks for looking into this.
As for the callbacks accumulating, I realize we've fixed this instance 
of that, but I'm going to file a bug recommending that we revisit the 
CallbackRegistry class so it doesn't get lost.
Cheers,
Mike
>
> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...] 
> Sent: Friday, June 06, 2008 10:10
> To: Stan West
> Cc: 'John Hunter'; 'matplotlib-dev list'
> Subject: Re: [matplotlib-devel] RegularPolyCollection inputs
> incollections_demo.py are wrong?
>
> You're absolutely right that it needs to be fixed.
>
> However, I wonder why the CallbackRegistry doesn't just store the callbacks
> in a set (or keys of a dictionary) such that multiple adds of the exact same
> function or method to the same signal couldn't occur. 
> Since there is no external state stored with each callback, I don't see a
> need for there ever being more than one of the same thing in there... 
> but maybe I'm missing something. Additionally, it seems like a C-ism to
> have to deal with callback ids when the callback objects themselves are
> already hashable and could be used to remove themselves.
>
> Cheers,
> Mike
>
> Stan West wrote:
> 
>> Quoting John Hunter:
>>
>> 
>> 
>>> Alternatively you can connect to the figure dpi_changed event -- 
>>> there is an example in Axes.cla
>>> 
>>> 
>> Regarding that example, each call to Axes.cla connects a new 
>> dpi_changed callback, but, as far as I can tell, the callback is never
>> 
> disconnected.
> 
>> Thus, each cla call augments the dict of dpi_changed figure callbacks:
>>
>> fig = figure()
>> ax = fig.add_subplot(1, 1, 1)
>> print len(fig.callbacks.callbacks['dpi_changed']) # only 1
>> for n in range(7): ax.cla()
>> print len(fig.callbacks.callbacks['dpi_changed']) # now 8
>>
>> Should cla store the connection id and, if there is a stored id from a 
>> prior call, disconnect the previous callback before connecting the new
>> 
> one?
> 
>> Stan
>>
>>
>> 
>> 
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I've not studied or used the CallbackRegistry, so I've got nothing to add on
that front. However, may I submit the attached work-around for Axes.cla?
Instead of offsetting the title using Affine2D().translate( ... figure.dpi
... ), it uses ScaledTranslation( ... figure.dpi_scale_trans ...). This
way, it seems to require no connection to the dpi_changed event (thereby
sidestepping the callback accumulation). Also, it constructs
titleOffsetTrans similarly to get_xaxis_text1_transform and its relatives,
and it reduces the hard-coded 5-point offset from three occurences to one,
which helps any future conversion to an rcParam.
I verified that the old and new code produce the same transformation matrix.
However, when I tried to retrieve the title's transformation, I received a
rather long traceback. It can be reproduced with
 import matplotlib.transforms as mtransforms
 mtransforms.ScaledTranslation(0, 0, mtransforms.IdentityTransform())
under 0.98.0. Now, how far have we deviated from the subject line? :-)
-----Original Message-----
From: Michael Droettboom [mailto:md...@st...] 
Sent: Friday, June 06, 2008 10:10
To: Stan West
Cc: 'John Hunter'; 'matplotlib-dev list'
Subject: Re: [matplotlib-devel] RegularPolyCollection inputs
incollections_demo.py are wrong?
You're absolutely right that it needs to be fixed.
However, I wonder why the CallbackRegistry doesn't just store the callbacks
in a set (or keys of a dictionary) such that multiple adds of the exact same
function or method to the same signal couldn't occur. 
Since there is no external state stored with each callback, I don't see a
need for there ever being more than one of the same thing in there... 
but maybe I'm missing something. Additionally, it seems like a C-ism to
have to deal with callback ids when the callback objects themselves are
already hashable and could be used to remove themselves.
Cheers,
Mike
Stan West wrote:
> Quoting John Hunter:
>
> 
>> Alternatively you can connect to the figure dpi_changed event -- 
>> there is an example in Axes.cla
>> 
>
> Regarding that example, each call to Axes.cla connects a new 
> dpi_changed callback, but, as far as I can tell, the callback is never
disconnected.
> Thus, each cla call augments the dict of dpi_changed figure callbacks:
>
> fig = figure()
> ax = fig.add_subplot(1, 1, 1)
> print len(fig.callbacks.callbacks['dpi_changed']) # only 1
> for n in range(7): ax.cla()
> print len(fig.callbacks.callbacks['dpi_changed']) # now 8
>
> Should cla store the connection id and, if there is a stored id from a 
> prior call, disconnect the previous callback before connecting the new
one?
>
> Stan
>
>
> 
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Olle Engdegård wrote:
> Hi,
> 
> Some more thoughts about hist():
> 
> A "range" parameter should be added and used in histogram()
Hi Olle,
 what do you mean by "range" parameter. What should this parameter 
actually do ?
 I just committed a patch to the trunk that adds the features as you 
and also Erik Tollerud proposed (expect for the range thing).
Manuel
> A new histogram should get a new colour, just like plot() does
> 
> The "step" type should default to fill=False
> 
> Actually, personally I hardly ever use bar histograms at all, so if 
> step-mode (unfilled) was made default I wouldn't complain...
> 
> And not directly related to hist():
> 
> I think the pan/zoom tool should be on by default when a new figure opens. 
> As it is now, we always need to press some button no matter what we want 
> to do. pan/zoom is a good guess (at least for me)!
> 
> 
> Thanks all developers for creating what has become my default plotting 
> tool! I will never leave the python shell again.
> 
> (from kitchen import coffee)
> 
> Cheers,
> Olle
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom wrote:
> Thanks. I have fixed 1), and added a "closed" kwarg to fill() and 
> Polygon.__init__() (which defaults to True to mimic behavior of 0.91 and 
> earlier). hist() has been updated to call fill() with closed=False.
> 
> Cheers,
> Mike
Great - thanks. So, I committed a patch with a further update of hist() 
introducing some new nice features.
Cheers,
 Manuel

You're absolutely right that it needs to be fixed.
However, I wonder why the CallbackRegistry doesn't just store the 
callbacks in a set (or keys of a dictionary) such that multiple adds of 
the exact same function or method to the same signal couldn't occur. 
Since there is no external state stored with each callback, I don't see 
a need for there ever being more than one of the same thing in there... 
but maybe I'm missing something. Additionally, it seems like a C-ism to 
have to deal with callback ids when the callback objects themselves are 
already hashable and could be used to remove themselves.
Cheers,
Mike
Stan West wrote:
> Quoting John Hunter:
>
> 
>> Alternatively you can connect to the figure dpi_changed event -- there is 
>> an example in Axes.cla
>> 
>
> Regarding that example, each call to Axes.cla connects a new dpi_changed
> callback, but, as far as I can tell, the callback is never disconnected.
> Thus, each cla call augments the dict of dpi_changed figure callbacks:
>
> fig = figure()
> ax = fig.add_subplot(1, 1, 1)
> print len(fig.callbacks.callbacks['dpi_changed']) # only 1
> for n in range(7): ax.cla()
> print len(fig.callbacks.callbacks['dpi_changed']) # now 8
>
> Should cla store the connection id and, if there is a stored id from a prior
> call, disconnect the previous callback before connecting the new one?
>
> Stan
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Quoting John Hunter:
> Alternatively you can connect to the figure dpi_changed event -- there is 
> an example in Axes.cla
Regarding that example, each call to Axes.cla connects a new dpi_changed
callback, but, as far as I can tell, the callback is never disconnected.
Thus, each cla call augments the dict of dpi_changed figure callbacks:
 fig = figure()
 ax = fig.add_subplot(1, 1, 1)
 print len(fig.callbacks.callbacks['dpi_changed']) # only 1
 for n in range(7): ax.cla()
 print len(fig.callbacks.callbacks['dpi_changed']) # now 8
Should cla store the connection id and, if there is a stored id from a prior
call, disconnect the previous callback before connecting the new one?
Stan

Thanks. I have fixed 1), and added a "closed" kwarg to fill() and 
Polygon.__init__() (which defaults to True to mimic behavior of 0.91 and 
earlier). hist() has been updated to call fill() with closed=False.
Cheers,
Mike
Manuel Metz wrote:
> Michael Droettboom wrote:
>> I've gone ahead and fixed this in the Polygon patch. As you point 
>> out, if someone wants an open polygon, they can use PathPatch, and 
>> Polygon was never able to do that before anyway.
>>
>> Cheers,
>> Mike
>
> Hi Mike,
>
> 1) I think that there is a bug in the patch: xy is a (N,2) array and I 
> get an error message for the line
>
> if len(xy) and xy[0] !=xy[-1]:
> ValueError: The truth value of an array with more than one element is 
> ambiguous. Use a.any() or a.all()
>
> so, I think it should really be
>
> if len(xy) and (xy[0] !=xy[-1]).any():
>
> 2) With this change the output hist doesn't look that good any more, 
> since it relies on the axes fill method. axes fill produced a filled 
> patch where the enclosing line was not closed (i.e. open at bottom of 
> the hist). So you could easily produce a nice unfilled step 
> line-histogram and I intended to make this the default behaviour for 
> hist(histtype='step'). Now the line gets closed which most users - I 
> guess - don't want to.
>
> So maybe it is needed to have a keyword for the axes fill method to 
> control whether the patch should be closed or not.
>
> Manuel
>
>> Eric Firing wrote:
>>> Michael Droettboom wrote:
>>>> Thanks. That's a good argument to do the close for fill(). I'll 
>>>> wait a bit to see if others chime in, but at least at that level it 
>>>> seems to be a no-brainer. Whether we want to do this in the 
>>>> Polygon patch is still an open question, perhaps.
>>> Mike,
>>>
>>> Let's see if anyone says anything either way. If no one does, then 
>>> I suggest that you should be the one to decide whether it makes 
>>> sense to make the change in patches or in fill. If the ultimate 
>>> decision is to change patches, then that is simpler, and there is no 
>>> point in making the slightly more complicated changes in axes. In 
>>> either case, I think the closing should be done only if a test shows 
>>> that the points passed in are not already closed.
>>>
>>> Looking at patches a little more, I think I would be inclined to put 
>>> the change in Polygon, on the grounds that a polygon simply is a 
>>> *closed* path specified by its vertices; there should be no need to 
>>> explicitly close it, although it may be more efficient to do so. 
>>> For the case where someone wants a general path, it looks like you 
>>> have thoughtfully provided the PathPatch object, so we don't really 
>>> lose generality by forcing the Polygon to be closed.
>>>
>>> Eric
>>>
>>>
>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Eric Firing wrote:
>>>>> Eric Firing wrote:
>>>>>> Michael Droettboom wrote:
>>>>>>> I'm not entirely certain this is desirable behavior -- what if 
>>>>>>> the user *wants* to draw an open-yet-filled polygon? How could 
>>>>>>> that be done? (Admittedly, it couldn't be done before). It 
>>>>>>> seems more general to require the user to close polygons.
>>>>>> True. I don't feel strongly about this. My guess is that at 
>>>>>> least at the level of the Axes.fill method, a user would almost 
>>>>>> never want the open-yet-filled case, but I could be guessing 
>>>>>> wrong, or the "almost" qualifier could be critical. We could do 
>>>>>> automatic closing only at that level, however.
>>>>>>
>>>>>> Maybe the best alternative is to leave the trunk behavior as it 
>>>>>> is, and make sure the documentation is very explicit about the 
>>>>>> need to supply a closed path. This change could be added to 
>>>>>> API_CHANGES, as well as to the Axes.fill docstring.
>>>>>>
>>>>>> Does anyone know how Matlab, IDL, etc. handle this?
>>>>> Here is the Matlab help text; matlab does automatically close the 
>>>>> polygons:
>>>>>
>>>>> fill(X,Y,C) creates filled polygons from the data in X and Y with 
>>>>> vertex color specified by C. C is a vector or matrix used as an 
>>>>> index into the colormap. If C is a row vector, length(C) must 
>>>>> equal size(X,2) and size(Y,2); if C is a column vector, length(C) 
>>>>> must equal size(X,1) and size(Y,1). If necessary, fill closes the 
>>>>> polygon by connecting the last vertex to the first.
>>>>>
>>>>> Eric
>>
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Not hard, I don't think. The following will give you a FT2Image object 
of the expression:
from matplotlib.mathtext import MathTextParser
mathtext_parser = MathTextParser("Bitmap")
ftimage = mathtext_parser.parse(r"$x^i$", 150)
 From the FT2Image, you can get an rgba buffer, and the width and the 
height.
Here's where it gets (a little) tricky -->
We have code to save RendererAgg buffers, and Image buffers, but nothing 
to take a pointer to raw C rgba buffer and width and height. We could 
a) depend on Gtk or Wx to save the mathtext PNG (which can do this now, 
see mathtext_wx.py), or b) create a new png-writing C-extension which 
would take a raw buffer, width, height and a filename/file object. 
Then, we could remove some code duplication by making _backend_agg.cpp 
and _image.cpp use that.
I won't have time to get to this immediately. Hopefully that's enough 
of a roadmap for someone else to take it.
Cheers,
Mike
John Hunter wrote:
> We are currently using latex dvipng pngs in our html docs to avoid the
> mathml browser limitations. I don't have latex on my OSX box, which
> is no really a big problem since I have ssh access to a fully
> configured linux box, but it would be really cool to drop this
> dependency and use mathtext instead. Truth in advertising after all
> -- eg in the mathtext chapter I'd much rather show them *our*
> equations than latex's, even though they are damn close.
>
> Michael - -how hard would it be to generate small PNGs of mpl rendered
> equations rather than use latex/dvipng here?
>
> JDH
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I think a get_edgecolor[s]() method is missing to Collection.
In addition, LineCollection is the only collection handled by Legend:
maybe adding the edgecolor() method would help to treat other
collections as Patches using (for example) the update_from() method
to create the simple Rectangle (used as a proxy for patches in
legends).
-- 
Stephane Raynaud

Hmm... Can't reproduce this here. Maybe it's Python 2.4-specific 
(which I don't have).
As a workaround, does replacing line 216 with:
 ParseFatalException.__init__(self, pe.pstr, pe.loc, pe.msg, 
pe.parserElement)
work?
Mike
John Hunter wrote:
> I'm getting an error with a mathtext string from the mathtext_examples:
>
> import matplotlib.pyplot as plt
> ax = plt.subplot(111)
> s = r"$W^{3\beta}_{\delta_1 \rho_1 \sigma_2} = U^{3\beta}_{\delta_1
> \rho_1} + \frac{1}{8 \pi 2} \int^{\alpha_2}_{\alpha_2} d
> \alpha^\prime_2 \left[\frac{ U^{2\beta}_{\delta_1 \rho_1} -
> \alpha^\prime_2U^{1\beta}_{\rho_1 \sigma_2} }{U^{0\beta}_{\rho_1
> \sigma_2}}\right]$"
>
> ax.text(1, 2, s)
> plt.show()
>
>
> johnh@flag:~> python tmp/qslogo.py
> Traceback (most recent call last):
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
> line 331, in expose_event
> self._render_figure(self._pixmap, w, h)
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py",
> line 75, in _render_figure
>
> ...snipsnip
>
> loc,tokens = self.parseImpl( instring, preloc, doActions )
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
> line 2304, in parseImpl
> raise ParseSyntaxException(pe)
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
> line 216, in __init__
> super(ParseSyntaxException, self).__init__(
> TypeError: super() argument 1 must be type, not classobj
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> I've gone ahead and fixed this in the Polygon patch. As you point out, 
> if someone wants an open polygon, they can use PathPatch, and Polygon 
> was never able to do that before anyway.
> 
> Cheers,
> Mike
Hi Mike,
1) I think that there is a bug in the patch: xy is a (N,2) array and I 
get an error message for the line
 if len(xy) and xy[0] !=xy[-1]:
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()
so, I think it should really be
 if len(xy) and (xy[0] !=xy[-1]).any():
2) With this change the output hist doesn't look that good any more, 
since it relies on the axes fill method. axes fill produced a filled 
patch where the enclosing line was not closed (i.e. open at bottom of 
the hist). So you could easily produce a nice unfilled step 
line-histogram and I intended to make this the default behaviour for 
hist(histtype='step'). Now the line gets closed which most users - I 
guess - don't want to.
 So maybe it is needed to have a keyword for the axes fill method to 
control whether the patch should be closed or not.
Manuel
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> Thanks. That's a good argument to do the close for fill(). I'll 
>>> wait a bit to see if others chime in, but at least at that level it 
>>> seems to be a no-brainer. Whether we want to do this in the Polygon 
>>> patch is still an open question, perhaps.
>> Mike,
>>
>> Let's see if anyone says anything either way. If no one does, then I 
>> suggest that you should be the one to decide whether it makes sense to 
>> make the change in patches or in fill. If the ultimate decision is to 
>> change patches, then that is simpler, and there is no point in making 
>> the slightly more complicated changes in axes. In either case, I 
>> think the closing should be done only if a test shows that the points 
>> passed in are not already closed.
>>
>> Looking at patches a little more, I think I would be inclined to put 
>> the change in Polygon, on the grounds that a polygon simply is a 
>> *closed* path specified by its vertices; there should be no need to 
>> explicitly close it, although it may be more efficient to do so. For 
>> the case where someone wants a general path, it looks like you have 
>> thoughtfully provided the PathPatch object, so we don't really lose 
>> generality by forcing the Polygon to be closed.
>>
>> Eric
>>
>>
>>
>>> Cheers,
>>> Mike
>>>
>>> Eric Firing wrote:
>>>> Eric Firing wrote:
>>>>> Michael Droettboom wrote:
>>>>>> I'm not entirely certain this is desirable behavior -- what if the 
>>>>>> user *wants* to draw an open-yet-filled polygon? How could that 
>>>>>> be done? (Admittedly, it couldn't be done before). It seems more 
>>>>>> general to require the user to close polygons.
>>>>> True. I don't feel strongly about this. My guess is that at least 
>>>>> at the level of the Axes.fill method, a user would almost never 
>>>>> want the open-yet-filled case, but I could be guessing wrong, or 
>>>>> the "almost" qualifier could be critical. We could do automatic 
>>>>> closing only at that level, however.
>>>>>
>>>>> Maybe the best alternative is to leave the trunk behavior as it is, 
>>>>> and make sure the documentation is very explicit about the need to 
>>>>> supply a closed path. This change could be added to API_CHANGES, 
>>>>> as well as to the Axes.fill docstring.
>>>>>
>>>>> Does anyone know how Matlab, IDL, etc. handle this?
>>>> Here is the Matlab help text; matlab does automatically close the 
>>>> polygons:
>>>>
>>>> fill(X,Y,C) creates filled polygons from the data in X and Y with 
>>>> vertex color specified by C. C is a vector or matrix used as an 
>>>> index into the colormap. If C is a row vector, length(C) must equal 
>>>> size(X,2) and size(Y,2); if C is a column vector, length(C) must 
>>>> equal size(X,1) and size(Y,1). If necessary, fill closes the polygon 
>>>> by connecting the last vertex to the first.
>>>>
>>>> Eric
> 
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

Darren has kick started a documentation effort in sphinx (which
resides in the doc subdir of the trunk) that is proving quite
successful. sphinx is ReST based, and is pretty easy to jump into.
As I understand it, Darren will have some time over the summer to
contribute to the effort (porting the existing docstrings in the API
documentation and the existing user's guide) but there is a lot to be
done. mpl has decent docs, certainly not great docs, and I'd like to
capitalize on the inertia Darren has created and try and strong arm
more of you into contributing to this effort. There is plenty to be
done, and even if you are no mpl expert there is lot you can
contribute.
I have organized a document in the developer's section
(doc/devel/outline.rst in the mpl src tree) listing units I think
would be good additions to the docs, suggesting authors in some cases
where I know someone is particularly well qualified, setting a status
field ("no author", "has author", "submitted", "complete") etc....
There are lots of ? symbols, which means either that we have no
candidate, or that my designee has not accepted the designation. Eg,
I may have nominated Eric Firing for a section, but he hasn't yet
agreed to do it, so I put a ? by his name. When he agrees to do it,
he can remove the ? by his name in svn. Importantly, every section
has an editor, and these fields are currently mostly populated by ?.
The editor responsibility is pretty light: read the chapter, check it
for style and correctness, and sign off on it.
By no means do we need to go this route -- we can continue to
contribute as we can, which has worked well in the rest of the mpl
code base and is currently working well for the new docs. If you find
this excessively bureaucratic or onerous, I'm happy to shelve the
approach. This is mostly an attempt to get more people involved in
the documentation effort by making a pubic show of the work that we
needs to be done, with bite size pieces that pepole can sign on for,
and it is less of an effort to get a formal review process in place.
But docs are an area where an "editor" can make a significant
contribution with a fairly minimal effort, so I think having a review
is a good addition. I stress in the outline.rst doc::
 It is probably easiest to be an editor. Once you have signed up to be
 an editor, if you have an author, pester the author for a submission
 every so often. If you don't have an author, find one, and then pester
 them! Your only two responsibilities are getting your author to
 produce and checking their work, so don't be shy. You *do not* need
 to be an expert in the subject you are editing -- you should know
 something about it and be willing to read, test, give feedback and
 pester!
Included below is the outline.rst doc from the devel documentation.
Since a lot of email readers mangle the spacing, you can also consult
the mpl src in docs/devel/outline.rst or the html rendered version at
http://matplotlib.sourceforge.net/mpldocs/devel/outline.html or the
src online at http://matplotlib.sourceforge.net/mpldocs/_sources/devel/outline.txt
.
Those of you who are developers can jump in and edit the outline doc,
assigning yourself, removing yourself, updating the status, etc...
Those of you who don't have commit rights but want to participate,
just respond here with author or editor positions you want and/or
submit a patch against the file. Also, I expect there are many
glaring holes in the topic list so do not be shy in making additions,
deletions or revisions.
JDH
outline.rst:
.. _outline:
************
Docs outline
************
Proposed chapters for the docs, who has responsibility for them, and
who reviews them. The "unit" doesn't have to be a full chapter
(though in some cases it will be), it may be a chapter or a section in
a chapter.
=============================== ==================== ===========
===================
User's guide unit Author Status Reviewer
=============================== ==================== ===========
===================
contouring Eric ? no author Perry ?
quiver plots Eric ? no author ?
quadmesh ? no author ?
images ? no author ?
histograms Manuel ? no author
Erik Tollerud ?
bar / errorbar ? no author ?
x-y plots ? no author ?
time series plots ? no author ?
date plots John has author ?
working with data John has author ?
custom ticking ? no author ?
masked data Eric ? no author ?
text ? no author ?
patches ? no author ?
legends ? no author ?
animation John has author ?
collections ? no author ?
mathtext Michael ? submitted John
fonts et al Michael ? no author ?
pyplot tut John submitted Eric ?
usetex Darren ? no author ?
configuration Darren ? preliminary ?
colormapping Perry ? no author Eric ?
win32 install Charlie ? no author ?
os x install Charlie ? no author ?
linux install ? no author ?
artist api John submitted ?
event handling John submitted ?
navigation John submitted ?
interactive usage ? no author ?
widgets ? no author ?
ui - gtk ? no author ?
ui - wx ? no author ?
ui - tk ? no author ?
ui - qt Darren ? no author ?
backend - pdf Jouni ? no author ?
backend - ps Darren ? no author ?
backend - svg ? no author ?
backend - agg ? no author ?
backend - cairo ? no author ?
=============================== ==================== ===========
===================
Here is the ouline for the dev guide, much less fleshed out
=============================== ==================== ===========
===================
Developer's guide unit Author Status Reviewer
=============================== ==================== ===========
===================
the renderer John has author Michael ?
the canvas John has author ?
the artist John has author ?
transforms Michael submitted John
documenting mpl Darren submitted ?
coding guide John submitted ?
and_much_more ? ? ?
=============================== ==================== ===========
===================
And we might want to do a similar table for the FAQ, but that may also
be overkill...
If you agree to author a unit, remove the question mark by your name
(or add your name if there is no candidate), and change the status to
"has author". Once you have completed draft and checked it in, you
can change the status to "submitted" and try to find a reviewer if you
don't have one. The reviewer should read your chapter, test it for
correctness (eg try your examples) and change the status to "complete"
when done.
You are free to lift and convert as much material from the web site or
the existing latex user's guide as you see fit. The more the better.
The UI chapters should give an example or two of using mpl with your
GUI and any relevant info, such as version, installation, config,
etc... The backend chapters should cover backend specific
configuration (eg PS only options), what features are missing, etc...
Please feel free to add units, volunteer to review or author a
chapter, etc...
It is probably easiest to be an editor. Once you have signed up to be
an editor, if you have an author pester the author for a submission
every so often. If you don't have an author, find one, and then pester
them! Your only two responsibilities are getting your author to
produce and checking their work, so don't be shy. You *do not* need
to be an expert in the subject you are editing -- you should know
something about it and be willing to read, test, give feedback and
pester!

Stan,
 I am cc'ing the dev list for archival reasons.
 I prefer the VS2003 build for several reasons. It is faster to 
build. The resulting code is faster and smaller too. This is due to 
Microsoft's compiler just being better than gcc. The process is not 
necessarily easier either way though. I will try to outline the steps 
from memory here, but definitely check out the information in the 
header of setupext.py and in the zip win32_static* files.
Tk backend:
Install the latest 8.4 release of ActiveTCL into "C:\Tcl".
GTK backend:
Install the lastest 2.10 version of the win32 gtk dev package into "C: 
\GTK". You can get these here "http://sourceforge.net/projects/gladewin32/ 
". gtk-2.12 does not work.
Install the latest 2.10 versions of pygtk.
GTK is a little off when it comes to pkg-config, so if you want the 
gtk backend I'll have to give you some more information. I am happy 
to do this, but it is late for me so I am just holding off right now.
WX is native python now, so nothing special is needed.
Obviously have numpy-1.1 installed.
This setup is the same for python 2.4 and 2.5.
Since you are going to be using svn, just extract the 
win32_static_vs.zip (for VS2003) in you matplotib folder. You should 
then have a win32_static folder in there.
Building a package is as simple as:
C:\Python25\python.exe setup.py build --compiler=msvc bdist_wininst
or
C:\Python25\python.exe setupegg.py build --compiler=msvc bdist_egg
If you want to use mingw, that just involves installing mingw to "C: 
\mingw" and using the win32_static.zip instead of the vs version.
Let me know how it goes,
Charlie
On Jun 5, 2008, at 1:28 PM, Stan West wrote:
> Thank you for the prompt reply. I have both compilers and have little
> preference between them at the outset. Are there significant 
> differences in
> either the build process or the result that I should consider?
>
>
> -----Original Message-----
> From: Charlie Moad [mailto:cw...@gm...]
> Sent: Thursday, June 05, 2008 12:30
> To: Stan West
> Subject: Re: Building matplotlib on Windows
>
> I should first ask if you are planning to build with mingw or visual 
> studio
> 2003?
>
> - Charlie
>
> On Thu, Jun 5, 2008 at 11:09 AM, Stan West <sta...@nr...> 
> wrote:
>> Greetings. I gather from the matplotlib mailing lists that you're the
>> expert on building it under Windows. I'd like to learn how to do that
>> to benefit from bug-fixes. What's involved? I started gathering the
>> dependencies mentioned in the COMPILING section of the INSTALL file.
>> That lead me to setupext.py, which led me to win32_static, where I
>> found files intended for Python 2.2 to 2.4. Figuring from that that
>> some of the build information might be outdated, I decided to contact
>> you directly and ask about the current state of things. I would 
>> appreciate
> any help you can offer.
>>
>> Kind regards,
>>
>> Stan West, Ph.D.
>> Research Physicist
>> U.S. NAVAL RESEARCH LABORATORY
>>
>
>

We are currently using latex dvipng pngs in our html docs to avoid the
mathml browser limitations. I don't have latex on my OSX box, which
is no really a big problem since I have ssh access to a fully
configured linux box, but it would be really cool to drop this
dependency and use mathtext instead. Truth in advertising after all
-- eg in the mathtext chapter I'd much rather show them *our*
equations than latex's, even though they are damn close.
Michael - -how hard would it be to generate small PNGs of mpl rendered
equations rather than use latex/dvipng here?
JDH

When I plot a matrix using pcolor, the size of the boxes don't match 
the input (each box is off by about 10% from the input coordinates).
I think the problem is caused by the new draw method in PolyCollection 
(added in revision 5403). If I revert to the previous version of 
collections.py, the boxes are displayed properly.
The below script is a simple test case. It should print the corners of 
the boxes on integer coordinates, but (on my computer, at least), the 
corners do not land on integer values.
:-Tony
======
N = 2
pts = np.arange(0, N+1)
X, Y = np.meshgrid(pts, pts)
col = plt.pcolor(X, Y, np.random.rand(N, N))
plt.show()

I'm getting an error with a mathtext string from the mathtext_examples:
import matplotlib.pyplot as plt
ax = plt.subplot(111)
s = r"$W^{3\beta}_{\delta_1 \rho_1 \sigma_2} = U^{3\beta}_{\delta_1
\rho_1} + \frac{1}{8 \pi 2} \int^{\alpha_2}_{\alpha_2} d
\alpha^\prime_2 \left[\frac{ U^{2\beta}_{\delta_1 \rho_1} -
\alpha^\prime_2U^{1\beta}_{\rho_1 \sigma_2} }{U^{0\beta}_{\rho_1
\sigma_2}}\right]$"
ax.text(1, 2, s)
plt.show()
johnh@flag:~> python tmp/qslogo.py
Traceback (most recent call last):
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
line 331, in expose_event
 self._render_figure(self._pixmap, w, h)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
...snipsnip
 loc,tokens = self.parseImpl( instring, preloc, doActions )
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
line 2304, in parseImpl
 raise ParseSyntaxException(pe)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyparsing.py",
line 216, in __init__
 super(ParseSyntaxException, self).__init__(
TypeError: super() argument 1 must be type, not classobj