matplotlib-devel Mailing List for matplotlib

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