matplotlib-devel Mailing List for matplotlib

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

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

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
> 

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

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 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?
Eric
> 
> This change occurred as part of the big push to draw everything as 
> polycurves. If we decide to support implicit closing of polygons, we 
> can probably do that within the polygon patch class.
> 
> Cheers,
> Mike
> 
> Eric Firing wrote:
>> Mike,
>>
>> Brian F. has correctly pointed out a change in behavior from the 
>> maintenance branch to the trunk: in the former, the fill command does 
>> not require that the polygon be closed--that is, that the last point 
>> coincide with the first. Hence, a filled rectangle can be specified 
>> with a list of 4 points. This seems to me like desirable behavior. 
>> After a very cursory look I have not spotted any obvious place where 
>> this change occurred, but I suspect it will be immediately obvious to 
>> you.
>>
>> Should the old behavior be restored?
>>
>> Thanks.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
>> From:
>> Bryan Fodness <bry...@gm...>
>> Date:
>> 2008年6月05日 08:38:59 -0400
>> To:
>> Eric Firing <ef...@ha...>
>>
>> To:
>> Eric Firing <ef...@ha...>
>> CC:
>> Matplotlib <Mat...@li...>
>>
>>
>> It seems like it does not connect the last point to the first point. 
>> This also happens with the matplotlib.patches Polygon.
>> 
>> 
>> from pylab import fill, xlim, ylim, savefig
>> x1, x2, y1, y2 = -4, 4, -4, 4
>> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
>> xlim(-5,5)
>> ylim(-5,5)
>> savefig('edge_test')
>>
>>
>> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <ef...@ha... 
>> <mailto:ef...@ha...>> wrote:
>>
>> Bryan Fodness wrote:
>>
>> I just upgraded to 0.98.0 and recreated a few graphs. I am
>> missing parts of the edges of a fill and polygon. Any
>> suggestions?
>>
>>
>> Please post an illustrative script, as simple as possible.
>>
>> Eric
>>
>>
>>
>>
>> -- 
>> "The game of science can accurately be described as a never-ending 
>> insult to human intelligence." - João Magueijo 
> 

BTW: Here's a patch if we decide to go that way:
Index: lib/matplotlib/patches.py
===================================================================
--- lib/matplotlib/patches.py (revision 5401)
+++ lib/matplotlib/patches.py (working copy)
@@ -540,6 +540,8 @@
 See Patch documentation for additional kwargs
 """
 Patch.__init__(self, **kwargs)
+ xy = np.asarray(xy, np.float_)
+ xy = np.concatenate([xy, [xy[0]]])
 self._path = Path(xy)
 __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
Eric Firing wrote:
> Mike,
>
> Brian F. has correctly pointed out a change in behavior from the 
> maintenance branch to the trunk: in the former, the fill command does 
> not require that the polygon be closed--that is, that the last point 
> coincide with the first. Hence, a filled rectangle can be specified 
> with a list of 4 points. This seems to me like desirable behavior. 
> After a very cursory look I have not spotted any obvious place where 
> this change occurred, but I suspect it will be immediately obvious to 
> you.
>
> Should the old behavior be restored?
>
> Thanks.
>
> Eric
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
> From:
> Bryan Fodness <bry...@gm...>
> Date:
> 2008年6月05日 08:38:59 -0400
> To:
> Eric Firing <ef...@ha...>
>
> To:
> Eric Firing <ef...@ha...>
> CC:
> Matplotlib <Mat...@li...>
>
>
> It seems like it does not connect the last point to the first point. 
> This also happens with the matplotlib.patches Polygon.
> 
> 
> from pylab import fill, xlim, ylim, savefig
> x1, x2, y1, y2 = -4, 4, -4, 4
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> xlim(-5,5)
> ylim(-5,5)
> savefig('edge_test')
>
>
> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
> Bryan Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
>
>
> Please post an illustrative script, as simple as possible.
>
> Eric
>
>
>
>
> -- 
> "The game of science can accurately be described as a never-ending 
> insult to human intelligence." - João Magueijo 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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.
This change occurred as part of the big push to draw everything as 
polycurves. If we decide to support implicit closing of polygons, we 
can probably do that within the polygon patch class.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> Brian F. has correctly pointed out a change in behavior from the 
> maintenance branch to the trunk: in the former, the fill command does 
> not require that the polygon be closed--that is, that the last point 
> coincide with the first. Hence, a filled rectangle can be specified 
> with a list of 4 points. This seems to me like desirable behavior. 
> After a very cursory look I have not spotted any obvious place where 
> this change occurred, but I suspect it will be immediately obvious to 
> you.
>
> Should the old behavior be restored?
>
> Thanks.
>
> Eric
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Matplotlib-users] missing lines on graph with upgrade to 0.98.0
> From:
> Bryan Fodness <bry...@gm...>
> Date:
> 2008年6月05日 08:38:59 -0400
> To:
> Eric Firing <ef...@ha...>
>
> To:
> Eric Firing <ef...@ha...>
> CC:
> Matplotlib <Mat...@li...>
>
>
> It seems like it does not connect the last point to the first point. 
> This also happens with the matplotlib.patches Polygon.
> 
> 
> from pylab import fill, xlim, ylim, savefig
> x1, x2, y1, y2 = -4, 4, -4, 4
> fill([x1,x2,x2,x1], [y1,y1,y2,y2], fc='None', ec='r')
> xlim(-5,5)
> ylim(-5,5)
> savefig('edge_test')
>
>
> On Thu, Jun 5, 2008 at 1:18 AM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
> Bryan Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
>
>
> Please post an illustrative script, as simple as possible.
>
> Eric
>
>
>
>
> -- 
> "The game of science can accurately be described as a never-ending 
> insult to human intelligence." - João Magueijo 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I added some custom CSS to our Sphinx HTML builds to add thin grey lines 
above each class, method and function definition. I was finding it very 
hard to visually see where each block of documentation begins. You may 
need to blitz your documentation build directory for this to work.
If others don't like this, I can remove it. It gets the ball rolling on 
other CSS changes we want to make, though I suspect we want to keep them 
to a minimum, as the Sphinx defaults are already pretty good.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Jun 5, 2008 at 12:02 PM, Michael Droettboom <md...@st...> wrote:
> Obviously hard-codes the dpi at plot-building time. This will be dynamic:
>
> trans = fig.dpi_scale_trans + transforms.Affine2D().scale(1.0/72.0)
Alternatively you can connect to the figure dpi_changed event -- there
is an example in Axes.cla
Thanks,
JDH

It's still a problem. It takes the dpi at the time of plot building and 
uses that to scale each of the objects. I have followed the example of 
RegularPolyCollection and now do this scaling during draw.
There was another dpi-related bug that affected the example only:
 trans = transforms.Affine2D().scale(fig.dpi/72.0)
Obviously hard-codes the dpi at plot-building time. This will be dynamic:
 trans = fig.dpi_scale_trans + transforms.Affine2D().scale(1.0/72.0)
I'll commit these to SVN shortly.
Cheers,
Mike
John Hunter wrote:
> On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <ts...@gm...> wrote:
> 
>> I think the arguments for RegularPolyCollection were changed from
>> 0.91.x to 0.98.0, but the example in collections_demo.py were not
>> changed.
>> 
>
> Thanks Tony,
>
> I committed this. Michael, when looking over the collection and
> scatter code to see what had replaced this dpi setting, I saw this in
> Axes.scatter:
>
>
> # MGDTODO: This has dpi problems
> # rescale verts
> rescale = np.sqrt(max(verts[:,0]**2+verts[:,1]**2))
> verts /= rescale
>
> Do we need to revisit the dpi scaling in this function or is this comment stale?
>
> 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

On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <ts...@gm...> wrote:
> I think the arguments for RegularPolyCollection were changed from
> 0.91.x to 0.98.0, but the example in collections_demo.py were not
> changed.
Thanks Tony,
I committed this. Michael, when looking over the collection and
scatter code to see what had replaced this dpi setting, I saw this in
Axes.scatter:
 # MGDTODO: This has dpi problems
 # rescale verts
 rescale = np.sqrt(max(verts[:,0]**2+verts[:,1]**2))
 verts /= rescale
Do we need to revisit the dpi scaling in this function or is this comment stale?
JDH

This happens because the axes rectangle is rounded to the nearest pixels 
by (essentially, hand-waving over the details) doing
 (int)x0, (int)y0, (int)x1, (int)y1
where x0, y0, x1, y1 are the bounds of the box, whereas images are 
rounded to the nearest pixels by:
 (int)x0, (int)y0, (int)x0 + (int)width, (int)y0 + (int)height
This should be fixable, but the implementation details make it a little 
tricky. I'm looking into this and will get back to you.
Cheers,
Mike
Stan West wrote:
> Hi. When I generate an AxesImage with, say, imshow(array([[0, 1], [1,
> 0]])), a one-pixel gap sometimes appears between the image and the bottom
> and/or right edges of the axis frame. The gap is sometimes shaded, as if by
> anti-aliasing. The presence and shading of the gap depends on the axis
> size, figure size, and figure dpi. In particular, the gap comes and goes as
> I resize the figure. I've observed this using the WXAgg and TkAgg backends
> under matplotlib 0.98.0.
>
> I checked the trackers and mailing list archives but found no previous
> mention of this behavior.
>
> I looked into image.py but didn't readily see what might be responsible.
> Would someone in the know be willing to investigate? Many thanks in
> advance.
>
>
>
> -------------------------------------------------------------------------
> 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

I think the arguments for RegularPolyCollection were changed from 
0.91.x to 0.98.0, but the example in collections_demo.py were not 
changed.
-Tony
Index: examples/api/collections_demo.py
===================================================================
--- examples/api/collections_demo.py	(revision 5400)
+++ examples/api/collections_demo.py	(working copy)
@@ -86,7 +86,7 @@
 a = fig.add_subplot(2,2,3)
-col = collections.RegularPolyCollection(fig.dpi, 7,
+col = collections.RegularPolyCollection(7,
 sizes = N.fabs(xx)*10.0, 
offsets=xyo,
 transOffset=a.transData)
 trans = transforms.Affine2D().scale(fig.dpi/72.0)

Hi. When I generate an AxesImage with, say, imshow(array([[0, 1], [1,
0]])), a one-pixel gap sometimes appears between the image and the bottom
and/or right edges of the axis frame. The gap is sometimes shaded, as if by
anti-aliasing. The presence and shading of the gap depends on the axis
size, figure size, and figure dpi. In particular, the gap comes and goes as
I resize the figure. I've observed this using the WXAgg and TkAgg backends
under matplotlib 0.98.0.
I checked the trackers and mailing list archives but found no previous
mention of this behavior.
I looked into image.py but didn't readily see what might be responsible.
Would someone in the know be willing to investigate? Many thanks in
advance.

On Wed, Jun 4, 2008 at 7:11 PM, Chris Fuller <cf...@th...> wrote:
> The old "classic" toolbar is out of sync with some API updates.
> This is what I get when running embedding_in_gtk2.py (after tweaking to use
> the classic toolbar)
Hey Chris, I made a few changes to restore support for the classic
toolbar in svn. These will come out in the 0.98.1 bug fix release
(what version are you using?) I could port these back to the 0.91
maintenance release, which is also broken but it would take some
additional work. I don't think many people are using this because
noone has complained and it's been broken for a while. If you are on
0.98, drop the attached ticker.py in site/packages/matplotlib and
backend_gtk.py in site-packages/matplotlib/backends/ until the next
bugfix release comes out.
JDH

On Thursday 05 June 2008 08:19:47 am Michael Droettboom wrote:
> I'm going through and preparing the transforms.py documentation for our
> new Sphinx setup. One of the things that's really important to document
> is the class heirarchy, but Sphinx doesn't appear to do that. I've
> looked at the Sphinx documentation and nothing comes up. I thought I'd
> check with this list first to see if I'm just missing something.
> Otherwise, I thought I would address this with the Sphinx folks to see
> what they would suggest. I think this would also be useful to have in
> the "artists" api documentation. For example, right now it isn't
> explicit that Line2D inherits from Artist. We can, I suppose, implement
> some sort of standard to always put the base classes in the docstring,
> but it would be nice to automate that.
I think this would be worth asking about on sphinx-dev, it seems like an 
important feature for the autodoc extension.

I'm going through and preparing the transforms.py documentation for our 
new Sphinx setup. One of the things that's really important to document 
is the class heirarchy, but Sphinx doesn't appear to do that. I've 
looked at the Sphinx documentation and nothing comes up. I thought I'd 
check with this list first to see if I'm just missing something. 
Otherwise, I thought I would address this with the Sphinx folks to see 
what they would suggest. I think this would also be useful to have in 
the "artists" api documentation. For example, right now it isn't 
explicit that Line2D inherits from Artist. We can, I suppose, implement 
some sort of standard to always put the base classes in the docstring, 
but it would be nice to automate that.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA