matplotlib-devel Mailing List for matplotlib (Page 4)

Jae-Joon Lee wrote:
> Andrew,
> 
> One of my worry is that this can results in inconsistent ouputs
> between backends. Your patch only affects backends with compositing
> capabilities. And backends such as ps backend will still render images
> at the bottom of all other artists.
PS backend already does things differently from others because it 
doesn't handle alpha, correct? Does the patch make this situation any 
worse?
Eric
> 
> I think it is often sufficient if we draw images at the bottom but
> respect zorders among images, and I guess this actually solves the
> issue of the original post.
> 
> So, my inclination is to respect zorders between images by default
> (images still drawn at the bottom), and optionally with all other
> artists.
> 
> Anyhow, I guess the cases affected by this issue is quite rare, and
> I'm actually fine if you submit the patch as is.
> 
> Regards,
> 
> -JJ
> 
> 
> 
> 
> On Mon, Nov 9, 2009 at 11:21 AM, Andrew Straw <str...@as...> wrote:
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>> ) The question is whether I should apply the attached patch.
>>
>> The worry is that someone is relying on the old behavior of images being
>> underneath everything else. To a degree, this could be achieved by having
>> the default image zorder be lower than everything else. Currently, imshow()
>> creates images with zorder 1, which is pretty low on the hierarchy, but
>> there may be something lower. (The artist base class default is 0, but the
>> Line2D class bumps it to 2.) All tests pass with the change, and manual
>> inspection of several of the pylab_examples don't show any difference before
>> and after the patch.
>>
>> -Andrew
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew,
One of my worry is that this can results in inconsistent ouputs
between backends. Your patch only affects backends with compositing
capabilities. And backends such as ps backend will still render images
at the bottom of all other artists.
I think it is often sufficient if we draw images at the bottom but
respect zorders among images, and I guess this actually solves the
issue of the original post.
So, my inclination is to respect zorders between images by default
(images still drawn at the bottom), and optionally with all other
artists.
Anyhow, I guess the cases affected by this issue is quite rare, and
I'm actually fine if you submit the patch as is.
Regards,
-JJ
On Mon, Nov 9, 2009 at 11:21 AM, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly
> ignored for imshow(). (See e.g.
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
> ) The question is whether I should apply the attached patch.
>
> The worry is that someone is relying on the old behavior of images being
> underneath everything else. To a degree, this could be achieved by having
> the default image zorder be lower than everything else. Currently, imshow()
> creates images with zorder 1, which is pretty low on the hierarchy, but
> there may be something lower. (The artist base class default is 0, but the
> Line2D class bumps it to 2.) All tests pass with the change, and manual
> inspection of several of the pylab_examples don't show any difference before
> and after the patch.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Andrew Straw wrote:
> Hi All,
> 
> I have addressed what I think is a long-standing wart: zorder is mostly 
> ignored for imshow(). (See e.g. 
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
> ) The question is whether I should apply the attached patch.
Andrew,
Looks good to me. I think you should go ahead.
Eric
> 
> The worry is that someone is relying on the old behavior of images being 
> underneath everything else. To a degree, this could be achieved by 
> having the default image zorder be lower than everything else. 
> Currently, imshow() creates images with zorder 1, which is pretty low on 
> the hierarchy, but there may be something lower. (The artist base class 
> default is 0, but the Line2D class bumps it to 2.) All tests pass with 
> the change, and manual inspection of several of the pylab_examples don't 
> show any difference before and after the patch.
> 
> -Andrew
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Nov 09, 2009 at 08:21:30AM -0800, Andrew Straw wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly 
> ignored for imshow(). (See e.g. 
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
> ) The question is whether I should apply the attached patch.
IMHO: go for it!
Gaël

Hi All,
I have addressed what I think is a long-standing wart: zorder is mostly 
ignored for imshow(). (See e.g. 
http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
) The question is whether I should apply the attached patch.
The worry is that someone is relying on the old behavior of images being 
underneath everything else. To a degree, this could be achieved by 
having the default image zorder be lower than everything else. 
Currently, imshow() creates images with zorder 1, which is pretty low on 
the hierarchy, but there may be something lower. (The artist base class 
default is 0, but the Line2D class bumps it to 2.) All tests pass with 
the change, and manual inspection of several of the pylab_examples don't 
show any difference before and after the patch.
-Andrew

You are right. The error disappeared after re-building the matploblib.
Thanks for pointing out this.
On Mon, Nov 9, 2009 at 8:41 AM, Michael Droettboom <md...@st...> wrote:
> I can't reproduce this here. These sorts of CXX errors are usually caused
> by distutils not rebuilding enough when things change. Can you try removing
> the build directory, rebuilding matplotlib, and then rebuilding the docs?
>
> Mike
>
>
> On 11/07/2009 12:10 PM, Gökhan Sever wrote:
>
> Hello,
>
> The latest check-out gives an error while trying to build the
> documentation. Hitting "q" in pdb prompt resumes the execution and finishes
> the creation successfully.
>
>
> [gsever@ccn doc]$ python make.py all
> Running Sphinx v0.6.2
> loading pickled environment... done
> animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite,
> pylab_examples, tests, units, user_interfaces, widgets,
> building [html]: targets for 470 source files that are out of date
> updating environment: 0 added, 13 changed, 0 removed
> generating thumbnails... Exception occurred while building, starting
> debugger:
> Traceback (most recent call last):
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py",
> line 172, in main
> app.build(all_files, filenames)
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
> line 130, in build
> self.builder.build_update()
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 265, in build_update
> 'out of date' % len(to_build))
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 285, in build
> purple, length):
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 131, in status_iterator
> for item in iterable:
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py",
> line 527, in update_generator
> app.emit('env-updated', self)
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
> line 222, in emit
> result.append(callback(self, *args))
> File
> "/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py",
> line 112, in gen_gallery
> pool.map(make_thumbnail, thumbnails.iteritems())
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
> return self.map_async(func, iterable, chunksize).get()
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
> raise self._value
> TypeError: PyCXX: Error creating object of type N2Py7SeqBaseINS_4CharEEE
> from <open file
> 'build/plot_directive/mpl_examples/pylab_examples/transoffset.png', mode
> 'rb' at 0xaa3fcf0>
> > /usr/lib/python2.6/multiprocessing/pool.py(422)get()
> -> raise self._value
> (Pdb)
>
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
-- 
Gökhan

I can't reproduce this here. These sorts of CXX errors are usually 
caused by distutils not rebuilding enough when things change. Can you 
try removing the build directory, rebuilding matplotlib, and then 
rebuilding the docs?
Mike
On 11/07/2009 12:10 PM, Gökhan Sever wrote:
> Hello,
>
> The latest check-out gives an error while trying to build the 
> documentation. Hitting "q" in pdb prompt resumes the execution and 
> finishes the creation successfully.
>
>
> [gsever@ccn doc]$ python make.py all
> Running Sphinx v0.6.2
> loading pickled environment... done
> animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite, 
> pylab_examples, tests, units, user_interfaces, widgets,
> building [html]: targets for 470 source files that are out of date
> updating environment: 0 added, 13 changed, 0 removed
> generating thumbnails... Exception occurred while building, starting 
> debugger:
> Traceback (most recent call last):
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py", 
> line 172, in main
> app.build(all_files, filenames)
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py", 
> line 130, in build
> self.builder.build_update()
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 265, in build_update
> 'out of date' % len(to_build))
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 285, in build
> purple, length):
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 131, in status_iterator
> for item in iterable:
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py", 
> line 527, in update_generator
> app.emit('env-updated', self)
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py", 
> line 222, in emit
> result.append(callback(self, *args))
> File 
> "/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py", 
> line 112, in gen_gallery
> pool.map(make_thumbnail, thumbnails.iteritems())
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
> return self.map_async(func, iterable, chunksize).get()
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
> raise self._value
> TypeError: PyCXX: Error creating object of type 
> N2Py7SeqBaseINS_4CharEEE from <open file 
> 'build/plot_directive/mpl_examples/pylab_examples/transoffset.png', 
> mode 'rb' at 0xaa3fcf0>
> > /usr/lib/python2.6/multiprocessing/pool.py(422)get()
> -> raise self._value
> (Pdb)
>
>
> -- 
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

So I think the change I suggested takes care of the floating point case, 
except that the vmin and vmax values don't default to 0.0 and 1.0. I 
wonder whether this is enough of a surprise to warrant some logic to set 
 vmin and vmax in some cases, such as iff all array values are floats 
in the range 0.0-1.0 and neither vmin nor vmax have been specified as 
arguments, then use vmin=0.0 and vmax=1.0. Should we aim to replicate 
the scipy imsave behaviour exactly? Another possible problem with the 
current behaviour is that single bit plane arrays currently get saved as 
RGB - I don't know if this can be changed easily.
Gary
Stéfan van der Walt wrote:
> Hi Gary
> 
> Sorry, I didn't even read the docstring since I have been using
> SciPy's "imsave" so far.
> 
> 2009年11月8日 Gary Ruben <gr...@bi...>:
>> This may be all you need. My tests (in the attached test.py) appear to
>> work. However, I don't think it's what you want. By default, figimage
>> even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging
>> from 0-1. What you probably want is a raw RGB mapping where pixel planes
>> are unsigned 8 bit values. I thought calling figimage with a
>> norm=no_norm(0,255) instance achieved this but it doesn't work as I
>> expect. So the first question is, what is the expected behaviour here,
>> and a follow-up is does anyone here understand how to do the colour
>> mapping to achieve it?
> 
> We assume that arrays of dtype uint8 represent intensities 0 through
> 255, and that floating point arrays are between 0-1.
> 
> Regards
> Stéfan
> 

Hi Gary
Sorry, I didn't even read the docstring since I have been using
SciPy's "imsave" so far.
2009年11月8日 Gary Ruben <gr...@bi...>:
> This may be all you need. My tests (in the attached test.py) appear to
> work. However, I don't think it's what you want. By default, figimage
> even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging
> from 0-1. What you probably want is a raw RGB mapping where pixel planes
> are unsigned 8 bit values. I thought calling figimage with a
> norm=no_norm(0,255) instance achieved this but it doesn't work as I
> expect. So the first question is, what is the expected behaviour here,
> and a follow-up is does anyone here understand how to do the colour
> mapping to achieve it?
We assume that arrays of dtype uint8 represent intensities 0 through
255, and that floating point arrays are between 0-1.
Regards
Stéfan

I guess you're right... I misunderstood the result of gc.collect() as the number of objects that could not be freed. The good news is that after fixing the bug I was looking at, there are no more objects that cannot be freed (gc.garbage is empty).
Thanks!
--Michiel.
--- On Sun, 11/8/09, Eric Firing <ef...@ha...> wrote:
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] Circular references in Figure
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Sunday, November 8, 2009, 1:43 AM
> Michiel de Hoon wrote:
> > Hi everybody,
> > 
> > I was looking at this bug about a memory leak:
> > 
> > https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
> > 
> > While this bug is now essentially fixed, I noticed
> that the Figure class contains some circular references that
> prevent it from being cleaned up by the garbage collector,
> which is effectively a memory leak. At least, for this
> code:
> > 
> >>>> from matplotlib.figure import Figure
> >>>> fig = Figure()
> >>>> del fig
> > 
> > the garbage collector reports 76 unreachable objects.
> This seems to be independent of which backend is being
> used.
> > 
> > Is it worthwhile to look deeper into it? Or should we
> accept that it is unavoidable that a library of the size of
> matplotlib will have circular references?
> > 
> 
> The purpose of the garbage collector is to handle the case
> of circular references--and mpl is full of circular
> references. When there are no circular references,
> then reference counting suffices. The garbage
> collector fails to handle circular references when an object
> has a __del__ method. I don't think we have that
> problem.
> 
> I am not actually seeing the result you describe,
> though. Using python from the interactive prompt--no
> ipython--when I do gc.collect() and then gc.get_count() I
> get back to the count from before instantiating the Figure.
> 
> >>> gc.get_count()
> (4, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> fig = Figure()
> >>> gc.get_count()
> (128, 0, 0)
> >>> del(fig)
> >>> gc.get_count()
> (128, 0, 0)
> >>> gc.collect()
> 76
> >>> gc.get_count()
> (4, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> 
> Eric
> 
> > 
> > --Michiel.
> > 
> 
 

Michiel de Hoon wrote:
> Hi everybody,
> 
> I was looking at this bug about a memory leak:
> 
> https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
> 
> While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code:
> 
>>>> from matplotlib.figure import Figure
>>>> fig = Figure()
>>>> del fig
> 
> the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used.
> 
> Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references?
> 
The purpose of the garbage collector is to handle the case of circular 
references--and mpl is full of circular references. When there are no 
circular references, then reference counting suffices. The garbage 
collector fails to handle circular references when an object has a 
__del__ method. I don't think we have that problem.
I am not actually seeing the result you describe, though. Using python 
from the interactive prompt--no ipython--when I do gc.collect() and then 
gc.get_count() I get back to the count from before instantiating the Figure.
 >>> gc.get_count()
(4, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> fig = Figure()
 >>> gc.get_count()
(128, 0, 0)
 >>> del(fig)
 >>> gc.get_count()
(128, 0, 0)
 >>> gc.collect()
76
 >>> gc.get_count()
(4, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
Eric
> 
> --Michiel.
> 

Hi everybody,
I was looking at this bug about a memory leak:
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code:
>>> from matplotlib.figure import Figure
>>> fig = Figure()
>>> del fig
the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used.
Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references?
--Michiel.
 

Currently imsave (implemented in the image.py file) only deals with 
greyscale single-plane images, i.e. 2D arrays, and in my defence, it's 
in the docstring, so I wouldn't call it a bug. However, it's a 
reasonable expectation that it support rgb and rgba since it is 
basically a thin wrapper around figimage.
My first try at this was to change the line
fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
to
fig = Figure(figsize=(arr.shape[1],arr.shape[0]), dpi=1, frameon=False)
since we just want to take the first two shape values.
(note figsize=arr.shape[:2][::-1] also works)
This may be all you need. My tests (in the attached test.py) appear to 
work. However, I don't think it's what you want. By default, figimage 
even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging 
from 0-1. What you probably want is a raw RGB mapping where pixel planes 
 are unsigned 8 bit values. I thought calling figimage with a 
norm=no_norm(0,255) instance achieved this but it doesn't work as I 
expect. So the first question is, what is the expected behaviour here, 
and a follow-up is does anyone here understand how to do the colour 
mapping to achieve it?
Gary
Stéfan van der Walt wrote:
> Hey all,
> 
> 2009年2月10日 Andrew Straw <str...@as...>:
>> Gary Ruben wrote:
>>> Hi Andrew,
>>>
>>> I don't have commit access. If you would check it in, that would be great.
>> Committed to the trunk in r6899... Thanks!
>>
>> And, sheesh, SourceForge's SVN server is slooow today for me, although
>> it seems to have finally improved.
> 
> While trying to write a matplotlib plugin for scikits.image, we
> noticed that `imsave` isn't currently working (that goes for the one
> in Ubuntu [0.99 I think] as well as the latest SVN):
> 
> Traceback (most recent call last):
> File "test_imsave.py", line 6, in <module>
> plt.imsave('test.jpg', img)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/pyplot.py",
> line 1412, in imsave
> return _imsave(*args, **kwargs)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/image.py",
> line 1025, in imsave
> fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/figure.py",
> line 180, in __init__
> self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
> TypeError: from_bounds() takes exactly 4 arguments (5 given)
> 
> The commands needed to reproduce the error are:
> 
> import matplotlib.pyplot as plt
> import numpy as np
> 
> img = np.ones((50, 50, 3), dtype=np.uint8)
> 
> plt.imsave('test.jpg', img)
> 
> Regards
> Stéfan
> 

Hey all,
2009年2月10日 Andrew Straw <str...@as...>:
> Gary Ruben wrote:
>> Hi Andrew,
>>
>> I don't have commit access. If you would check it in, that would be great.
>
> Committed to the trunk in r6899... Thanks!
>
> And, sheesh, SourceForge's SVN server is slooow today for me, although
> it seems to have finally improved.
While trying to write a matplotlib plugin for scikits.image, we
noticed that `imsave` isn't currently working (that goes for the one
in Ubuntu [0.99 I think] as well as the latest SVN):
Traceback (most recent call last):
 File "test_imsave.py", line 6, in <module>
 plt.imsave('test.jpg', img)
 File "/Users/stefan/lib/python2.6/site-packages/matplotlib/pyplot.py",
line 1412, in imsave
 return _imsave(*args, **kwargs)
 File "/Users/stefan/lib/python2.6/site-packages/matplotlib/image.py",
line 1025, in imsave
 fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
 File "/Users/stefan/lib/python2.6/site-packages/matplotlib/figure.py",
line 180, in __init__
 self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
TypeError: from_bounds() takes exactly 4 arguments (5 given)
The commands needed to reproduce the error are:
import matplotlib.pyplot as plt
import numpy as np
img = np.ones((50, 50, 3), dtype=np.uint8)
plt.imsave('test.jpg', img)
Regards
Stéfan

On Sat, Nov 7, 2009 at 9:53 AM, Pierre Raybaut <co...@py...> wrote:
>>
>> On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut <co...@py...>
>> wrote:
>>
>>>
>>> > A simpler fix would be:
>>> >
>>> > ? ? ? ?class FigureWindow(QtGui.QMainWindow):
>>> > ? ? ? ? ? ?def __init__(self):
>>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).__init__()
>>> >
>>> > ? ? ? ? ? ?def closeEvent(self, event):
>>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).closeEvent(event)
>>> > ? ? ? ? ? ? ? ?self.emit(QtCore.SIGNAL('destroyed()'))
>>> >
>>> > and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
>>>
>>
>> I am pretty sure this is not caused by matplotlib, but rather a
>> regression in PyQt4 that will be fixed in the next release. There is a
>> post on the PyQt mailing list titled "Regressions on destruction of
>> objects?" and a note in the development snapshots changelog. If I try
>> your example with PyQt4-4.5.4, it works fine, but it crashes with
>> 4.6.1. I will revisit the issue once PyQt4-4.7 is released.
>>
>> Darren
>>
>
> I completely agree -- in the meantime I checked that despite the QMainWindow
> instance has been destroyed, the 'destroyed()' signal is not emitted, so the
> problem is definitely coming from PyQt4, not matplotlib.
>
> However, to help unfortunate users of PyQt4 v4.6 and v4.6.1, I've added the
> following workaround in Spyder (Spyder is monkey patching matplotlib anyway,
> to integrate mpl dockable figures in Spyder's GUI) -- other users may be
> interested to patch their matplotlib installation
> (matplotlib/backends/backend_qt4.py):
>
> # Add this before "FigureManagerQT" class
> class FigureWindow(QMainWindow):
>  def __init__(self):
>    super(FigureWindow, self).__init__()     def closeEvent(self,
> event):
>    super(FigureWindow, self).closeEvent(event)
>    if PYQT_VERSION_STR.startswith('4.6'):
>      self.emit(SIGNAL('destroyed()'))
> # Replace "QtGui.QMainWindow" by "FigureWindow" in "FigureManagerQT"'s
> constructor
>
> I hope this will be fixed in v4.6.2.
Me too. And thank you for posting the report and a workaround.

Hello,
The latest check-out gives an error while trying to build the documentation.
Hitting "q" in pdb prompt resumes the execution and finishes the creation
successfully.
[gsever@ccn doc]$ python make.py all
Running Sphinx v0.6.2
loading pickled environment... done
animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite,
pylab_examples, tests, units, user_interfaces, widgets,
building [html]: targets for 470 source files that are out of date
updating environment: 0 added, 13 changed, 0 removed
generating thumbnails... Exception occurred while building, starting
debugger:
Traceback (most recent call last):
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py",
line 172, in main
 app.build(all_files, filenames)
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
line 130, in build
 self.builder.build_update()
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 265, in build_update
 'out of date' % len(to_build))
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 285, in build
 purple, length):
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 131, in status_iterator
 for item in iterable:
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py",
line 527, in update_generator
 app.emit('env-updated', self)
 File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
line 222, in emit
 result.append(callback(self, *args))
 File
"/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py",
line 112, in gen_gallery
 pool.map(make_thumbnail, thumbnails.iteritems())
 File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
 return self.map_async(func, iterable, chunksize).get()
 File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
 raise self._value
TypeError: PyCXX: Error creating object of type N2Py7SeqBaseINS_4CharEEE
from <open file
'build/plot_directive/mpl_examples/pylab_examples/transoffset.png', mode
'rb' at 0xaa3fcf0>
> /usr/lib/python2.6/multiprocessing/pool.py(422)get()
-> raise self._value
(Pdb)
-- 
Gökhan

>
> On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut <co...@py...> wrote:
> 
>> > A simpler fix would be:
>> >
>> > ? ? ? ?class FigureWindow(QtGui.QMainWindow):
>> > ? ? ? ? ? ?def __init__(self):
>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).__init__()
>> >
>> > ? ? ? ? ? ?def closeEvent(self, event):
>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).closeEvent(event)
>> > ? ? ? ? ? ? ? ?self.emit(QtCore.SIGNAL('destroyed()'))
>> >
>> > and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
>> 
>
> I am pretty sure this is not caused by matplotlib, but rather a
> regression in PyQt4 that will be fixed in the next release. There is a
> post on the PyQt mailing list titled "Regressions on destruction of
> objects?" and a note in the development snapshots changelog. If I try
> your example with PyQt4-4.5.4, it works fine, but it crashes with
> 4.6.1. I will revisit the issue once PyQt4-4.7 is released.
>
> Darren
> 
I completely agree -- in the meantime I checked that despite the 
QMainWindow instance has been destroyed, the 'destroyed()' signal is not 
emitted, so the problem is definitely coming from PyQt4, not matplotlib.
However, to help unfortunate users of PyQt4 v4.6 and v4.6.1, I've added 
the following workaround in Spyder (Spyder is monkey patching matplotlib 
anyway, to integrate mpl dockable figures in Spyder's GUI) -- other 
users may be interested to patch their matplotlib installation 
(matplotlib/backends/backend_qt4.py):
# Add this before "FigureManagerQT" class
class FigureWindow(QMainWindow):
 def __init__(self):
 super(FigureWindow, self).__init__() 
 def closeEvent(self, event):
 super(FigureWindow, self).closeEvent(event)
 if PYQT_VERSION_STR.startswith('4.6'):
 self.emit(SIGNAL('destroyed()'))
# Replace "QtGui.QMainWindow" by "FigureWindow" in "FigureManagerQT"'s 
constructor
I hope this will be fixed in v4.6.2.
Cheers,
Pierre

Hi,
After a lot of head-scratching, I figured out that I need to set an
appropriate charmap when fonts are loaded. Well, as a matter of fact,
I even didn't know if fonts can have multiple charmaps.
Anyhow, I just committed a patch that I think fix the issue.
Please update your mpl and see if it works.
Regards,
-JJ
On Thu, Nov 5, 2009 at 9:18 AM, tcb <the...@gm...> wrote:
> Hi,
>
> That's ok- let me know if there's anything I can help with. I can't see what
> textpath.py is doing any different on mac or linux, and it seems to find the
> right glyph code- but I suspect freetype on the mac is passing back the
> wrong glyph. So it would seem to point to a freetype problem, or a font
> problem, and specific to the mac.
>
> I did install the latest amsfonts but the bug was still there.
>
> tcb
>
> On Wed, Nov 4, 2009 at 2:32 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> It seems that this could be bug in textpath.py that picks up wrong
>> glyph. Unfortunately, I cannot spend much time on this until the end
>> of this week.
>>
>> As a matter of fact, I'm far from an expert on this issue. While I
>> wrote the textpaht.py, the code is largely based on the code in the
>> pdf_backend and svg_backend. So, I hope someone who is more
>> knowledgeable than me step in.
>>
>> On the other hand, it seems that some glyph-name related bug has
>> recently fixed in the amsfont. And, this might be related to the
>> current issue.
>>
>> http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README
>>
>> I'm not sure what version of amsfont you're using but, can you try to
>> update them to newest 3.0.2 version? And see if that makes any change?
>>
>> I'll try to look into this later this week.
>> Regards,
>>
>> -JJ
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 10:26 PM, tcb <the...@gm...> wrote:
>> > hi,
>> >
>> > i took a quick look at what is going on here- but I have still not quite
>> > found the problem. From tracing things back into the ft2font code, it
>> > seems
>> > that the wrong glyph index is getting passed in or used somewhere. I put
>> > this debugging code into ft2font.cpp in "FT2Font::load_glyph"
>> >
>> > #define MAX_LEN   1024
>> >  unsigned char bf[MAX_LEN];
>> >  FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
>> >  std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ <<
>> > " "
>> > << glyph_index << " "
>> >    << num << " "
>> >    << face->family_name << " "
>> >    << face->style_name << " "
>> >    << FT_Get_Postscript_Name(face) << " "
>> >    << "[ " << bf << " ]"
>> >    << std::endl;
>> >
>> > I modified your example demo_text_path2.py to just load the single
>> > symbol
>> > '\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' -
>> > and
>> > the output I get is this from the command line:
>> >
>> > FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium
>> > CMMI12
>> > [ xi ]
>> >
>> > so, it seems to pick the correct font but the wrong glyph name (xi
>> > instead
>> > of pi)- I am not sure what the index should be. What gets displayed is
>> > the
>> > '\xi' symbol- you can see from the first output I sent that '\pi' has
>> > been
>> > replaced by '\xi' - the indexes of all the symbols are just offset by
>> > one, I
>> > think.
>> >
>> > If the correct glyph index is being passed to ft2font, then it could
>> > very
>> > well be a problem with freetype.
>> >
>> > regards
>> >
>> >
>> > On Tue, Nov 3, 2009 at 6:19 PM, tcb <the...@gm...> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Yes, with the pdfbackend, and using just the plain text code (with
>> >> usetex=True), the correct output is produced (for Text but not
>> >> TextPath). I
>> >> modified your demo_text_path2.py to draw with text, and attached the
>> >> output.
>> >>
>> >> This is the terminal output from running your attached code. I am using
>> >> the texlive 2009 distribution- which appears to be working fine, I have
>> >> not
>> >> noticed any problems at all. What is the difference between the bluesky
>> >> and
>> >> amsfonts?
>> >>
>> >> texname, type1name, enc, char_id
>> >> cmex10
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
>> >> None CMEX10-34
>> >> cmsy10
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> >> None CMSY10-49
>> >> cmex10
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> >> None CMEX10-88
>> >> cmmi12
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
>> >> None CMMI12-110
>> >> cmr17
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMR17-61
>> >> cmr17
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMR17-49
>> >> cmsy10
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMSY10-0
>> >> cmmi12
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMMI12-101
>> >> cmmi12
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMMI12-105
>> >> cmmi12
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMMI12-25
>> >> cmr17
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMR17-50
>> >> cmmi12
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMMI12-110
>> >> cmex10
>> >>
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> >> None CMEX10-35
>> >> phvr8r
>> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
>> >> /usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
>> >> Nimbus%20Sans%20L%20Regular-2
>> >>
>> >> regards,
>> >>
>> >>
>> >> On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee...@gm...>
>> >> wrote:
>> >>>
>> >>> On Tue, Nov 3, 2009 at 4:23 AM, tcb <the...@gm...> wrote:
>> >>> > and if I convert the dvi with dvipng, it all seems in order
>> >>> > (demo_text_path_tex.png). I haven't looked closely into how the
>> >>> > textpath
>> >>> > stuff works, but I thought it would read the dvi as a path, and
>> >>> > display
>> >>> > that
>> >>> > on the screen- if that is correct then I dont know how it ends up
>> >>> > displaying
>> >>> > a different symbol from what is in the dvi file.
>> >>>
>> >>> Well, dvi files only contains the name of the tex font. What textpath
>> >>> does is to pick up corresponding type I font and convert them to path
>> >>> using the freetype library (as far as I know, this is what dvipng and
>> >>> matplotlib pdf backend does). So, my guess is that, textpath is
>> >>> somehow picking up wrong fonts, or wrong glyphs.
>> >>>
>> >>> The code works fine at least in my mac os X tiger w/ texlive 2008, and
>> >>> in ubuntu with texlive 2007.
>> >>> As I don't have any access to mac os X 10.6, it would be hard to track
>> >>> down what is wrong. Here are a few more test I wish you to run.
>> >>>
>> >>> *) Check if pdf backend produces a correct result. Do not use textpath
>> >>> example, but simply use text command with usetex=True, and see if the
>> >>> pdf output is okay. FWIW, the textpath code is largely borrowed from
>> >>> the pdfbackend.
>> >>>
>> >>> *) Run the attached code, and post the terminal output. The output is
>> >>> basically the name of the tex font and the name of the substituted
>> >>> type1 font, etc. For your reference, here is my output.
>> >>>
>> >>> texname, type1name, enc, char_id
>> >>> cmex10
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb
>> >>> None CMEX10-34
>> >>> cmsy10
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>> >>> None CMSY10-49
>> >>> cmex10
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>> >>> None CMEX10-88
>> >>> cmmi12
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb
>> >>> None CMMI12-110
>> >>> cmr17
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMR17-61
>> >>> cmr17
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMR17-49
>> >>> cmsy10
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMSY10-0
>> >>> cmmi12
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMMI12-101
>> >>> cmmi12
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMMI12-105
>> >>> cmmi12
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMMI12-25
>> >>> cmr17
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMR17-50
>> >>> cmmi12
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMMI12-110
>> >>> cmex10
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>> >>> None CMEX10-35
>> >>> pncr8r
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb
>> >>> /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc
>> >>> Century%20Schoolbook%20L%20Roman-232
>> >>>
>> >>> Regards,
>> >>>
>> >>> -JJ
>> >>
>> >
>> >
>
>

This is a good suggestion.
I've committed your patch (with a slight modification so it works with 
the STIX fonts also) in SVN r7944 and r7645.
Thanks, and more patches always welcome!
Mike
Sean Arms wrote:
> Greetings,
>
> I've been checking out the code in lib/matplotlib/mathtext.py with the
> hope of adding support for a "widebar". I have something that works,
> although unlike \widetilde and \widehat, I can only find one glyph and
> it's in cmr10. I've attached a patch that adds \widebar support using
> svn rev 7943 if anyone is interested!
>
> Cheers!
>
> Sean Arms
> University of Oklahoma
> School of Meteorology
> PhD Candidate
>
> Index: lib/matplotlib/mathtext.py
> ===================================================================
> --- lib/matplotlib/mathtext.py (revision 7943)
> +++ lib/matplotlib/mathtext.py (working copy)
> @@ -769,6 +769,7 @@
> ('ex', '\x64')],
> r'\widetilde': [('rm', '\x7e'), ('ex', '\x65'), ('ex', '\x66'),
> ('ex', '\x67')],
> + r'\widebar' : [('rm', '\xB9')],
> r'<' : [('cal', 'h'), ('ex', 'D')],
> r'>' : [('cal', 'i'), ('ex', 'E')]
> }
> @@ -2481,7 +2482,7 @@
> r'overleftarrow' : r'\leftarrow'
> }
>
> - _wide_accents = set(r"widehat widetilde".split())
> + _wide_accents = set(r"widehat widetilde widebar".split())
>
> def accent(self, s, loc, toks):
> assert(len(toks)==1)
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut <co...@py...> wrote:
> A simpler fix would be:
>
>    class FigureWindow(QtGui.QMainWindow):
>      def __init__(self):
>        super(FigureWindow, self).__init__()
>
>      def closeEvent(self, event):
>        super(FigureWindow, self).closeEvent(event)
>        self.emit(QtCore.SIGNAL('destroyed()'))
>
> and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
I am pretty sure this is not caused by matplotlib, but rather a
regression in PyQt4 that will be fixed in the next release. There is a
post on the PyQt mailing list titled "Regressions on destruction of
objects?" and a note in the development snapshots changelog. If I try
your example with PyQt4-4.5.4, it works fine, but it crashes with
4.6.1. I will revisit the issue once PyQt4-4.7 is released.
Darren

Greetings,
I've been checking out the code in lib/matplotlib/mathtext.py with the
hope of adding support for a "widebar". I have something that works,
although unlike \widetilde and \widehat, I can only find one glyph and
it's in cmr10. I've attached a patch that adds \widebar support using
svn rev 7943 if anyone is interested!
Cheers!
Sean Arms
University of Oklahoma
School of Meteorology
PhD Candidate
Index: lib/matplotlib/mathtext.py
===================================================================
--- lib/matplotlib/mathtext.py (revision 7943)
+++ lib/matplotlib/mathtext.py (working copy)
@@ -769,6 +769,7 @@
 ('ex', '\x64')],
 r'\widetilde': [('rm', '\x7e'), ('ex', '\x65'), ('ex', '\x66'),
 ('ex', '\x67')],
+ r'\widebar' : [('rm', '\xB9')],
 r'<' : [('cal', 'h'), ('ex', 'D')],
 r'>' : [('cal', 'i'), ('ex', 'E')]
 }
@@ -2481,7 +2482,7 @@
 r'overleftarrow' : r'\leftarrow'
 }
- _wide_accents = set(r"widehat widetilde".split())
+ _wide_accents = set(r"widehat widetilde widebar".split())
 def accent(self, s, loc, toks):
 assert(len(toks)==1)

Hi Pierre,
Thanks for the report. I'll have a look as soon as I get a chance.
Darren
On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut <co...@py...> wrote:
> A simpler fix would be:
>
>    class FigureWindow(QtGui.QMainWindow):
>      def __init__(self):
>        super(FigureWindow, self).__init__()
>
>      def closeEvent(self, event):
>        super(FigureWindow, self).closeEvent(event)
>        self.emit(QtCore.SIGNAL('destroyed()'))
>
> and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
>
> Pierre
>
> Pierre Raybaut a écrit :
>> Hi,
>>
>> Some Spyder users have reported a critical bug occuring with
>> matplotlib 0.99's Qt4 backend and PyQt4 v4.6 (e.g. in Ubuntu Karmic).
>>
>>
>> Here is the traceback after calling 'plot([])', closing figure and
>> calling again 'plot([])' (e.g. in an IPython session with options
>> --pylab and --q4thread):
>>
>> Traceback (most recent call last):
>> File "/home/rick/Temp/untitled0.py", line 9, in <module>
>>  show()
>> File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4.py",
>> line 63, in show
>>  manager.window.show()
>> RuntimeError: underlying C/C++ object has been deleted
>>
>>
>> I found out that the 'destroyed()' signal (connected in class
>> FigureManagerQT) is never emitted when figure is closed.
>> As a consequence, SIP is not very happy when trying to draw a deleted
>> object...
>>
>> I made the following changes to make it work:
>>
>> # New class to clarify code in FigureManagerQT
>> class FigureWindow(QtGui.QMainWindow):
>>  def __init__(self, num, canvas, close_callback):
>>    super(FigureWindow, self).__init__()
>>    self.close_callback = close_callback
>>    self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
>>    self.setWindowTitle("Figure %d" % num)
>>    image = os.path.join(matplotlib.rcParams['datapath'],
>>               'images', 'matplotlib.png')
>>    self.setWindowIcon(QtGui.QIcon(image))
>>    self._destroying = False
>>    self.setCentralWidget(canvas)
>>    if matplotlib.is_interactive():
>>      self.show()
>>      def closeEvent(self, event):
>>    super(FigureWindow, self).closeEvent(event)
>>    self.close_callback()
>>
>> class FigureManagerQT( FigureManagerBase ):
>>  """
>>  Public attributes
>>
>>  canvas   : The FigureCanvas instance
>>  num     : The Figure number
>>  toolbar   : The qt.QToolBar
>>  window   : The qt.QMainWindow
>>  """
>>
>>  def __init__( self, canvas, num ):
>>    if DEBUG: print 'FigureManagerQT.%s' % fn_name()
>>    FigureManagerBase.__init__( self, canvas, num )
>>    self.canvas = canvas
>>
>>    # Give the keyboard focus to the figure instead of the manager
>>    self.canvas.setFocusPolicy( QtCore.Qt.ClickFocus )
>>    self.canvas.setFocus()
>>
>>    self.window = FigureWindow(num, self.canvas, self._widgetclosed)
>>    self.toolbar = self._get_toolbar(self.canvas, self.window)
>>    self.window.addToolBar(self.toolbar)
>>    QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
>>                self.window.statusBar().showMessage)
>> # [...]
>>
>> And we may now remove the "QtCore.QObject.disconnect" for the no
>> longer existing signal 'destroyed()' in method 'FigureManagerQT.
>> destroy'.
>>
>> HTH
>>
>> Cheers,
>> Pierre
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Nov 3, 2009 at 11:28 AM, Fernando Perez <fpe...@gm...> wrote:
> if you reside in the San Francisco Bay Area, you may be interested in
> a meeting we'll be having tomorrow November 4 (2-4 pm), as part of our
> regular py4science meeting series. Guido van Rossum, the creator of
> the Python language, will visit for a session where we will first do a
> very rapid overview of a number of scientific projects that use Python
> (in a lightning talk format) and then we will have an open discussion
> with Guido with hopefully interesting questions going in both
> directions. The meeting is open to all, bring your questions!
Video of the event:
http://www.archive.org/details/ucb_py4science_2009_11_04_Guido_van_Rossum
Slides: http://fperez.org/py4science/2009_guido_ucb/index.html
A few blog posts about it:
- Guido: http://neopythonic.blogspot.com/2009/11/python-in-scientific-world.html
- Jarrod: http://jarrodmillman.blogspot.com/2009/11/visit-from-guido-van-rossum.html
- Matthew: http://nipyworld.blogspot.com/2009/11/guido-van-rossum-talks-about-python-3.html
- Me: http://fdoperez.blogspot.com/2009/11/guido-van-rossum-at-uc-berkeleys.html
Attendance was excellent (standing room only, and I saw some people
leave because it was too full). Many thanks to all the presenters!
Cheers,
f

Hi,
That's ok- let me know if there's anything I can help with. I can't see what
textpath.py is doing any different on mac or linux, and it seems to find the
right glyph code- but I suspect freetype on the mac is passing back the
wrong glyph. So it would seem to point to a freetype problem, or a font
problem, and specific to the mac.
I did install the latest amsfonts but the bug was still there.
tcb
On Wed, Nov 4, 2009 at 2:32 PM, Jae-Joon Lee <lee...@gm...> wrote:
> It seems that this could be bug in textpath.py that picks up wrong
> glyph. Unfortunately, I cannot spend much time on this until the end
> of this week.
>
> As a matter of fact, I'm far from an expert on this issue. While I
> wrote the textpaht.py, the code is largely based on the code in the
> pdf_backend and svg_backend. So, I hope someone who is more
> knowledgeable than me step in.
>
> On the other hand, it seems that some glyph-name related bug has
> recently fixed in the amsfont. And, this might be related to the
> current issue.
>
> http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README
>
> I'm not sure what version of amsfont you're using but, can you try to
> update them to newest 3.0.2 version? And see if that makes any change?
>
> I'll try to look into this later this week.
> Regards,
>
> -JJ
>
>
>
>
> On Tue, Nov 3, 2009 at 10:26 PM, tcb <the...@gm...<thecolourblue%2B...@gm...>>
> wrote:
> > hi,
> >
> > i took a quick look at what is going on here- but I have still not quite
> > found the problem. From tracing things back into the ft2font code, it
> seems
> > that the wrong glyph index is getting passed in or used somewhere. I put
> > this debugging code into ft2font.cpp in "FT2Font::load_glyph"
> >
> > #define MAX_LEN 1024
> > unsigned char bf[MAX_LEN];
> > FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
> > std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ << "
> "
> > << glyph_index << " "
> > << num << " "
> > << face->family_name << " "
> > << face->style_name << " "
> > << FT_Get_Postscript_Name(face) << " "
> > << "[ " << bf << " ]"
> > << std::endl;
> >
> > I modified your example demo_text_path2.py to just load the single symbol
> > '\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' - and
> > the output I get is this from the command line:
> >
> > FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium
> CMMI12
> > [ xi ]
> >
> > so, it seems to pick the correct font but the wrong glyph name (xi
> instead
> > of pi)- I am not sure what the index should be. What gets displayed is
> the
> > '\xi' symbol- you can see from the first output I sent that '\pi' has
> been
> > replaced by '\xi' - the indexes of all the symbols are just offset by
> one, I
> > think.
> >
> > If the correct glyph index is being passed to ft2font, then it could very
> > well be a problem with freetype.
> >
> > regards
> >
> >
> > On Tue, Nov 3, 2009 at 6:19 PM, tcb <the...@gm...<thecolourblue%2B...@gm...>>
> wrote:
> >>
> >> Hi,
> >>
> >> Yes, with the pdfbackend, and using just the plain text code (with
> >> usetex=True), the correct output is produced (for Text but not
> TextPath). I
> >> modified your demo_text_path2.py to draw with text, and attached the
> output.
> >>
> >> This is the terminal output from running your attached code. I am using
> >> the texlive 2009 distribution- which appears to be working fine, I have
> not
> >> noticed any problems at all. What is the difference between the bluesky
> and
> >> amsfonts?
> >>
> >> texname, type1name, enc, char_id
> >> cmex10
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
> >> None CMEX10-34
> >> cmsy10
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
> >> None CMSY10-49
> >> cmex10
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
> >> None CMEX10-88
> >> cmmi12
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
> >> None CMMI12-110
> >> cmr17
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMR17-61
> >> cmr17
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMR17-49
> >> cmsy10
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMSY10-0
> >> cmmi12
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMMI12-101
> >> cmmi12
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMMI12-105
> >> cmmi12
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMMI12-25
> >> cmr17
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMR17-50
> >> cmmi12
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMMI12-110
> >> cmex10
> >>
> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
> >> None CMEX10-35
> >> phvr8r
> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
> >> /usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
> >> Nimbus%20Sans%20L%20Regular-2
> >>
> >> regards,
> >>
> >>
> >> On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee...@gm...>
> wrote:
> >>>
> >>> On Tue, Nov 3, 2009 at 4:23 AM, tcb <the...@gm...<thecolourblue%2B...@gm...>>
> wrote:
> >>> > and if I convert the dvi with dvipng, it all seems in order
> >>> > (demo_text_path_tex.png). I haven't looked closely into how the
> >>> > textpath
> >>> > stuff works, but I thought it would read the dvi as a path, and
> display
> >>> > that
> >>> > on the screen- if that is correct then I dont know how it ends up
> >>> > displaying
> >>> > a different symbol from what is in the dvi file.
> >>>
> >>> Well, dvi files only contains the name of the tex font. What textpath
> >>> does is to pick up corresponding type I font and convert them to path
> >>> using the freetype library (as far as I know, this is what dvipng and
> >>> matplotlib pdf backend does). So, my guess is that, textpath is
> >>> somehow picking up wrong fonts, or wrong glyphs.
> >>>
> >>> The code works fine at least in my mac os X tiger w/ texlive 2008, and
> >>> in ubuntu with texlive 2007.
> >>> As I don't have any access to mac os X 10.6, it would be hard to track
> >>> down what is wrong. Here are a few more test I wish you to run.
> >>>
> >>> *) Check if pdf backend produces a correct result. Do not use textpath
> >>> example, but simply use text command with usetex=True, and see if the
> >>> pdf output is okay. FWIW, the textpath code is largely borrowed from
> >>> the pdfbackend.
> >>>
> >>> *) Run the attached code, and post the terminal output. The output is
> >>> basically the name of the tex font and the name of the substituted
> >>> type1 font, etc. For your reference, here is my output.
> >>>
> >>> texname, type1name, enc, char_id
> >>> cmex10
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb
> >>> None CMEX10-34
> >>> cmsy10
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
> >>> None CMSY10-49
> >>> cmex10
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
> >>> None CMEX10-88
> >>> cmmi12
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb
> >>> None CMMI12-110
> >>> cmr17
> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMR17-61
> >>> cmr17
> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMR17-49
> >>> cmsy10
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMSY10-0
> >>> cmmi12
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMMI12-101
> >>> cmmi12
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMMI12-105
> >>> cmmi12
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMMI12-25
> >>> cmr17
> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMR17-50
> >>> cmmi12
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMMI12-110
> >>> cmex10
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
> >>> None CMEX10-35
> >>> pncr8r
> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb
> >>> /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc
> >>> Century%20Schoolbook%20L%20Roman-232
> >>>
> >>> Regards,
> >>>
> >>> -JJ
> >>
> >
> >
>

A simpler fix would be:
 class FigureWindow(QtGui.QMainWindow):
 def __init__(self):
 super(FigureWindow, self).__init__()
 
 def closeEvent(self, event):
 super(FigureWindow, self).closeEvent(event)
 self.emit(QtCore.SIGNAL('destroyed()'))
and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
Pierre
Pierre Raybaut a écrit :
> Hi,
>
> Some Spyder users have reported a critical bug occuring with 
> matplotlib 0.99's Qt4 backend and PyQt4 v4.6 (e.g. in Ubuntu Karmic).
>
>
> Here is the traceback after calling 'plot([])', closing figure and 
> calling again 'plot([])' (e.g. in an IPython session with options 
> --pylab and --q4thread):
>
> Traceback (most recent call last):
> File "/home/rick/Temp/untitled0.py", line 9, in <module>
> show()
> File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4.py",
> line 63, in show
> manager.window.show()
> RuntimeError: underlying C/C++ object has been deleted
>
>
> I found out that the 'destroyed()' signal (connected in class 
> FigureManagerQT) is never emitted when figure is closed.
> As a consequence, SIP is not very happy when trying to draw a deleted 
> object...
>
> I made the following changes to make it work:
>
> # New class to clarify code in FigureManagerQT
> class FigureWindow(QtGui.QMainWindow):
> def __init__(self, num, canvas, close_callback):
> super(FigureWindow, self).__init__()
> self.close_callback = close_callback
> self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
> self.setWindowTitle("Figure %d" % num)
> image = os.path.join(matplotlib.rcParams['datapath'],
> 'images', 'matplotlib.png')
> self.setWindowIcon(QtGui.QIcon(image))
> self._destroying = False
> self.setCentralWidget(canvas)
> if matplotlib.is_interactive():
> self.show()
> def closeEvent(self, event):
> super(FigureWindow, self).closeEvent(event)
> self.close_callback()
>
> class FigureManagerQT( FigureManagerBase ):
> """
> Public attributes
>
> canvas : The FigureCanvas instance
> num : The Figure number
> toolbar : The qt.QToolBar
> window : The qt.QMainWindow
> """
>
> def __init__( self, canvas, num ):
> if DEBUG: print 'FigureManagerQT.%s' % fn_name()
> FigureManagerBase.__init__( self, canvas, num )
> self.canvas = canvas
>
> # Give the keyboard focus to the figure instead of the manager
> self.canvas.setFocusPolicy( QtCore.Qt.ClickFocus )
> self.canvas.setFocus()
>
> self.window = FigureWindow(num, self.canvas, self._widgetclosed)
> self.toolbar = self._get_toolbar(self.canvas, self.window)
> self.window.addToolBar(self.toolbar)
> QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
> self.window.statusBar().showMessage)
> # [...]
>
> And we may now remove the "QtCore.QObject.disconnect" for the no 
> longer existing signal 'destroyed()' in method 'FigureManagerQT.
> destroy'.
>
> HTH
>
> Cheers,
> Pierre
>
>