matplotlib-devel Mailing List for matplotlib (Page 5)

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

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

Eric Firing wrote:
> jas...@cr... wrote:
>> How hard would it be to extend the quiver command to support curved 
>> arrows? For example, the U and V arrays, instead of giving just the 
>> vector, could for each vector give a list of x coordinates and a list 
>> of y coordinates for each segment of a vector. Additionally, C could 
>> give either a color for the curved vector, or a list of colors for 
>> each segment of the vector.
>
> Very hard. I would recommend starting from scratch with a new class. 
> I think that very little of the present Quiver code would be usable.
Okay. Thanks for the estimate.
Jason

2009年11月3日 John Hunter <jd...@gm...>:
> Perhaps you can file a bug report on the tracker so Michiel can look into it?
Here we go:
https://sourceforge.net/tracker/?func=detail&aid=2891502&group_id=80706&atid=560720
Cheers
Stéfan

jas...@cr... wrote:
> How hard would it be to extend the quiver command to support curved 
> arrows? For example, the U and V arrays, instead of giving just the 
> vector, could for each vector give a list of x coordinates and a list of 
> y coordinates for each segment of a vector. Additionally, C could give 
> either a color for the curved vector, or a list of colors for each 
> segment of the vector.
Very hard. I would recommend starting from scratch with a new class. I 
think that very little of the present Quiver code would be usable.
Eric

How hard would it be to extend the quiver command to support curved 
arrows? For example, the U and V arrays, instead of giving just the 
vector, could for each vector give a list of x coordinates and a list of 
y coordinates for each segment of a vector. Additionally, C could give 
either a color for the curved vector, or a list of colors for each 
segment of the vector.
Thanks,
Jason

Hi folks,
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!
More details on this seminar series (including location) can be found here:
https://cirl.berkeley.edu/view/Py4Science
Cheers,
f

2009年11月3日 Stéfan van der Walt <st...@su...>:
> Hi JJ
>
> 2009年11月2日 Jae-Joon Lee <lee...@gm...>:
>> I now think this is not the dpi issue.
>> Can you check the size of your figure in mac os X backend, after the
>> plot is drawn?
>>
>> print f.get_size_inches()
>>
>> 8x6 inch is the default.
>
> It says [4, 2.52], so I think you are right!
>
>> So, my recommendation is to use smaller dpi for screen display
>> (default is something like 80), and increase the dpi when saving the
>> figure ("savefig" has a dpi parameter).
>
> This fixes the problem. Now, why does the MacOSX end do this when
> none of the others do?
>
> Thanks for helping me track this down!
Perhaps you can file a bug report on the tracker so Michiel can look into it?
Thanks,
JDH

On Mon, Nov 2, 2009 at 4:59 PM, Matthew West <mw...@il...> wrote:
> Hi,
>
> The PolyCollection class currently closes the path for each polygon by
> adding a last point the same as the first point. This means that the
> line joins will be different on this point. I've submitted a patch to
> make PolyCollection use Path.CLOSEPOLY to close the path, which makes
> the line joins on the stroking correct.
>
> See https://sourceforge.net/tracker/?func=detail&aid=2890979&group_id=80706&atid=560722
>
> There is also a small test script and the current and expected output
> attached to the above tracker entry.
>
> Please let me know if there is some other way this should be fixed.
>
Project Admin
Hide
I attempted to apply this but it triggered three regression test failures --
this may be simply because the regression test is expecting a different
number of verts in the simplification tests, but I am going to assign this
to Michael, who wrote the tests, so he can update the tests and the patch
at the same time
For future patches, if possible, please submit an svn diff as these are
easier to apply.
Thanks,
JDH
======================================================================
FAIL: matplotlib.tests.test_simplification.test_noise
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py",
line 72, in test_noise
assert len(simplified) == 2675
AssertionError
======================================================================
FAIL: matplotlib.tests.test_simplification.test_sine_plus_noise
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py",
line 89, in test_sine_plus_noise
assert len(simplified) == 628
AssertionError
======================================================================
FAIL: matplotlib.tests.test_simplification.test_start_with_moveto
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py",
line 182, in runTest
self.test(*self.arg)
File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py",
line 166, in test_start_with_moveto
assert segs[0][1] == Path.MOVETO
AssertionError
----------------------------------------------------------------------
Ran 107 tests in 74.927s
FAILED (KNOWNFAIL=34, errors=3, failures=3)

Hi JJ
2009年11月2日 Jae-Joon Lee <lee...@gm...>:
> I now think this is not the dpi issue.
> Can you check the size of your figure in mac os X backend, after the
> plot is drawn?
>
> print f.get_size_inches()
>
> 8x6 inch is the default.
It says [4, 2.52], so I think you are right!
> So, my recommendation is to use smaller dpi for screen display
> (default is something like 80), and increase the dpi when saving the
> figure ("savefig" has a dpi parameter).
This fixes the problem. Now, why does the MacOSX end do this when
none of the others do?
Thanks for helping me track this down!
Stéfan

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

No problem. Many of the developers don't follow the tracker as closely 
as the mailing list. I'll look at this bug later today.
Cheers,
Mike
Robert Schroll wrote:
> Dear all,
>
> I hope this isn't considered gauche, but:
>
> A few weeks ago, I added a bug [1] I had found when saving figures from 
> the toolbar with a WX-based backend. I think it's a simple issue, and I 
> included the simple fix that worked for me. Since then there's been no 
> apparent activity on it. Is there something more I need to do on it?
>
> If someone is already taking care of it, I apologize for hassling you. 
> But if the fix is as simple as I think it is, it would be a shame to 
> have it fall through the cracks.
>
> Thanks,
> Robert
>
> [1]https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2880836&group_id=80706
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> 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

Thanks for the report.
And I wonder if you can provide us some more details of your
configuration and do some more tests.
1) You're not using usetex mode, correct?
2) Does your mathtext work fine otherwise? I mean, with the ordinary
text command, not the textpath example.
Regards,
-JJ
On Mon, Nov 2, 2009 at 2:45 PM, tcb <the...@gm...> wrote:
> Hi,
>
> I am running the svn version of matplotlib on a mac (OSX 10.6 with latest
> macports), and there is a problem with the output from demo_text_path.py. It
> does give the correct output on linux, so I assume the problem is either
> with the installed fonts on the mac, or with the mathtext code (in
> particular the tables in _mathtext_data.py). From the output, you can see
> that the text is correct in the upper subplot, but in the lower one, where
> is uses mathematical symbols, it is garbled. I get the same output for
> different backends (I have checked with macosx, GTKAgg and pdf).
>
>
> If I can help to figure out the problem, please let me know,
>
> regards,
>
> tcb
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Dear all,
I hope this isn't considered gauche, but:
A few weeks ago, I added a bug [1] I had found when saving figures from 
the toolbar with a WX-based backend. I think it's a simple issue, and I 
included the simple fix that worked for me. Since then there's been no 
apparent activity on it. Is there something more I need to do on it?
If someone is already taking care of it, I apologize for hassling you. 
But if the fix is as simple as I think it is, it would be a shame to 
have it fall through the cracks.
Thanks,
Robert
[1]https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2880836&group_id=80706

Hi,
I was following the directions found here:
http://old.nabble.com/ImportError:-No-module-named-mplot3d-td24291309.html
which consists of:
svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
matplotlib
python setup.py install
-when I executed that last command I get the following:
wayne@x61:matplotlib$ sudo python setup.py install
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 1.0.svn
 python: 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC
 4.3.3]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.3.0
 freetype2: 9.20.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.27
 Tkinter: Tkinter: 70220, Tk: 8.5, Tcl: 8.5
 wxPython: no
 * WXAgg's accelerator requires `wx-config'. The
 * `wx-config' executable could not be located in any
 * directory of the PATH environment variable. If you
 * want to build WXAgg, and wx-config is in some
 * other location or has some other name, set the
 * WX_CONFIG environment variable to the full path of
 * the executable like so: export WX_CONFIG=/usr/lib
 * /wxPython-2.6.1.0-gtk2-unicode/bin/wx-config
 Gtk+: gtk+: 2.16.1, glib: 2.20.1, pygtk: 2.14.1,
 pygobject: 2.16.1
 Mac OS X native: no
 Qt: no
 Qt4: no
 Cairo: 1.4.12
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: 1.4.1
 pytz: 2008h
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: 8.64
 latex: 3.141592
 pdftops: 0.10.5
[Edit setup.cfg to suppress the above messages]
============================================================================
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends', 'matplotlib.projections',
'matplotlib.testing', 'matplotlib.testing.jpl_units', 'matplotlib.tests',
'mpl_toolkits', 'mpl_toolkits.mplot3d', 'mpl_toolkits.axes_grid',
'matplotlib.sphinxext', 'matplotlib.numerix', 'matplotlib.numerix.mlab', '
matplotlib.numerix.ma', 'matplotlib.numerix.linear_algebra',
'matplotlib.numerix.random_array', 'matplotlib.numerix.fft',
'matplotlib.delaunay']
running install
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.linux-i686-2.6/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf ->
build/lib.linux-i686-2.6/matplotlib/mpl-data
running build_ext
building 'matplotlib.backends._tkagg' extension
g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-i686-2.6/src/agg_py_transforms.o
build/temp.linux-i686-2.6/src/_tkagg.o
build/temp.linux-i686-2.6/CXX/cxx_extensions.o
build/temp.linux-i686-2.6/CXX/cxxsupport.o
build/temp.linux-i686-2.6/CXX/IndirectPythonInterface.o
build/temp.linux-i686-2.6/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/local/lib -ltk8.5 -ltcl8.5 -lstdc++ -lm -lfreetype -lz -lstdc++ -lm
-o build/lib.linux-i686-2.6/matplotlib/backends/_tkagg.so
/usr/bin/ld: cannot find -ltk8.5
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1
I've searched for the ltk8.5 error on google and wasn't able to find
anything that helped. One that looked promising but failed to help:
http://old.nabble.com/Building-matplotlib-0.99.1.1:-cannot-find--ltk8.5-(whereas-0.91.4-works)-td25677275.html#a25677275
I really want the mpl_toolkits.mplot3d library...
Thanks for any help,
Wayne

Hi,
The PolyCollection class currently closes the path for each polygon by 
adding a last point the same as the first point. This means that the 
line joins will be different on this point. I've submitted a patch to 
make PolyCollection use Path.CLOSEPOLY to close the path, which makes 
the line joins on the stroking correct.
See https://sourceforge.net/tracker/?func=detail&aid=2890979&group_id=80706&atid=560722
There is also a small test script and the current and expected output 
attached to the above tracker entry.
Please let me know if there is some other way this should be fixed.
Best regards,
Matt.

I now think this is not the dpi issue.
Can you check the size of your figure in mac os X backend, after the
plot is drawn?
print f.get_size_inches()
8x6 inch is the default.
With dpi setting of 300 and bigger, the figure size (in pixel) will be
likely larger than your monitor size. And it seems that in mac os X
backend, the figure gets shrunken to fit the display, effectively
reducing the figuresize.
So, my recommendation is to use smaller dpi for screen display
(default is something like 80), and increase the dpi when saving the
figure ("savefig" has a dpi parameter).
Regards,
-JJ
2009年11月2日 Stéfan van der Walt <st...@su...>:
> Hi JJ
>
>> this bug has been fixed in the svn.
>
> Unfortunately, I still see the same behaviour using the latest version
> from SVN. As noted earlier, I work around the issue now by switching
> to the pdf backend.
>
> Regards
> Stéfan
>

Hi JJ
2009年11月1日 Jae-Joon Lee <lee...@gm...>:
> Can you try to install matplotlib again, after removing old ones.
> The mac os X had a bug that does take care of the dpi. But I guess
> this bug has been fixed in the svn.
Unfortunately, I still see the same behaviour using the latest version
from SVN. As noted earlier, I work around the issue now by switching
to the pdf backend.
Regards
Stéfan

Stefan,
Can you try to install matplotlib again, after removing old ones.
The mac os X had a bug that does take care of the dpi. But I guess
this bug has been fixed in the svn.
http://old.nabble.com/Re%3A-Font-size-and-savefig-p23337463.html
-JJ
2009年11月1日 Stéfan van der Walt <st...@su...>:
> Hi John
>
> 2009年11月1日 John Hunter <jd...@gm...>:
>> To avoid the overlap on the titles and ticks, you will want to play
>> with the font size of the ticks and title, but most importantly the
>> subplots_adjust parameters hspace and wspace.
>> If using a suptitle, you may also want to adjust top.
>
> Thanks for the advice, I'll play around with those parameters.
>
> I was surprised that this works fine under Linux, so I tried switching
> to the PDF backend on OSX, and now everything renders perfectly.
> Could it be that the MacOSX backend does something strange?
>
> Regards
> Stéfan
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi John
2009年11月1日 John Hunter <jd...@gm...>:
> To avoid the overlap on the titles and ticks, you will want to play
> with the font size of the ticks and title, but most importantly the
> subplots_adjust parameters hspace and wspace.
> If using a suptitle, you may also want to adjust top.
Thanks for the advice, I'll play around with those parameters.
I was surprised that this works fine under Linux, so I tried switching
to the PDF backend on OSX, and now everything renders perfectly.
Could it be that the MacOSX backend does something strange?
Regards
Stéfan

2009年11月1日 Stéfan van der Walt <st...@su...>:
> 2009年10月31日 Eric Firing <ef...@ha...>:
>> You forgot the attachment.
>
> I hate it when that happens -- here it is!
Hey Stéfan,
To avoid the overlap on the titles and ticks, you will want to play
with the font size of the ticks and title, but most importantly the
subplots_adjust parameters hspace and wspace.
If using a suptitle, you may also want to adjust top.
Eg,
# you can also click on the "subplots adjust" toolbar icon to play with the
# settings to get something that looks right and then hard code this
fig.subplots_adjust(hspace=0.4, wspace=0.4)
for ax in ax1, ax2, ax3, ax4:
 ax.title.set_fontsize(11)
 for label in ax.get_xticklabels() + ax.get_yticklabels)():
 label.set_fontsize(9)
You can also use rc parameters to control the defaults:
http://matplotlib.sourceforge.net/users/customizing.html
JDH

2009年10月31日 Eric Firing <ef...@ha...>:
> You forgot the attachment.
I hate it when that happens -- here it is!
Cheers
Stéfan