matplotlib-users Mailing List for matplotlib

Using matplotlib 0.98.5 on OSX 10.5, the following error
occurs for many key_press events using the standard
connect class - letter such as c,v,s etc (and most important, backspace)
Exception in Tkinter callback
Traceback (most recent call last):
 File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk/Tkinter.py",
line 1403, in __call__
 return self.func(*args)
 File 
"/Library/Python/2.5/site-packages/matplotlib/backends/backend_tkagg.py",line 
312, in key_press
 FigureCanvasBase.key_press_event(self, key, guiEvent=event)
 File "/Library/Python/2.5/site-packages/matplotlib/backend_bases.py", 
line 1122, in
key_press_event
 self.callbacks.process(s, event)
 File "/Library/Python/2.5/site-packages/matplotlib/cbook.py", line 
155, in process
 func(*args, **kwargs)
 File "/Library/Python/2.5/site-packages/matplotlib/backend_bases.py", 
line 1626, in key_press
 self.canvas.toolbar.back()
AttributeError: FigureCanvasTkAgg instance has no attribute 'toolbar'
would a full list of the "bad" keys help?
J

Hi Mike,
2008年12月15日 Michael Droettboom <md...@st...>:
> Angus McMorland wrote:
>> I think I've copied the usage suggested by the 'writing mathtext' page
>> in the mpl documentation (i.e. looking at its rst source [1]). That is
>> to say, the appearance of $ and the lack of \ are produced by the
>> extension, and not by me.
>>
> I see what you're saying now. Sorry for the assumption.
No problems. Thank-you for developing these great tools.
<snip>
> You'll need to use raw strings (prefix the """ with an r) so that the \a
> will appear in the final string.
>> I get this error:
>>
>> writing output... index modules/calculate
>> /usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
>> Warning: Could not render math expression $lpha$
>> Warning)
>> /usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
>> Warning: Could not render math expression $lpha = 2$
>> Warning)
Excellent - the use of raw docstrings _does_ fix the errors during the
sphinx build.
> That doesn't seem to be the root of this problem, however, as these strings
> should at least render to *something*, though probably not what you want.
>
> The warning is hiding the real error here. In mathmpl.py, after the line
> where the warning is emitted:
>
> warnings.warn("Could not render math expression %s" % latex,
> Warning)
>
> Add the line:
>
> raise
>
> and then post the output to this list?
Just an FYI so you can probably tell what was going on, without the
curative r'', and with raise in place, the error reported was:
writing output... index modules/calculate
/usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
Warning: Could not render math expression $lpha$
 Warning)
Exception occurred:
 File "/usr/lib/python2.5/site-packages/matplotlib/mathtext.py", line
1963, in raise_error
 raise ParseFatalException(msg + "\n" + s)
ParseFatalException: Expected end of math '$'
$lpha$ (at char 0), (line:1, col:1)
Next, I initially got no pictures (a silent fail) in my browser, but I
traced that back to an assumption that mathmpl makes that sphinx-build
is being run from the html directory, whereas I was running it from
one higher up the hierarchy (my docs directory). Running sphinx-build
from the appropriate location makes it all work.
Obviously this is fine for mpl's needs (and mine too, now I know the
tricks). If, however, you're interested in making this a little more
robust for general usage, then the path handling probably needs
tweaking. I think the problem is that mathmpl.latex2html puts the
_static directory in the current directory sphinx-build is run from,
whereas in the html it points to '../_static/', which is not the same
thing whenever html pages are being rendered at deeper directory
levels.
> Thanks,
> Mike
Thanks for the help,
Angus.
-- 
AJC McMorland
Post-doctoral research fellow
Neurobiology, University of Pittsburgh

On Mon, Dec 15, 2008 at 2:49 PM, Mauro Cavalcanti <mau...@gm...> wrote:
> 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of
> <setupext.CleanUpFile instance at 0x874ab2c>> ignored
>
> But everthing seems to be working OK, as I tested my application with
> the newly installed version and it runs without crashes.
Yes, this is the cruft I referred to earlier in my email. distutils
is putting copies of all our _somefile.cpp into the tarball as
somefile.cpp (leading underscore stripped). I'm attaching my post to
the distutils-sig mailing list just in case anyone here has any
insight. I think the warnings are harmless, but they are irritating
distutils-sig post
============
I am seeing some strange behavior in files with leading underscores.
I have some python extension code with names like::
 src/_somefile.cpp
and in my sdist they are being added in duplicate, one with the
leading underscore removed.
 src/somefile.cpp
 src/_somefile.cpp
This is causing easy_setup to complain at the end about not being able
to remove certain files.
 jdhunter@bic128:mpl98.5> find . -name backend_agg.cpp
 jdhunter@bic128:mpl98.5> find . -name _backend_agg.cpp
 ./src/_backend_agg.cpp
 jdhunter@bic128:mpl98.5> python setup.py sdist > sdist.out
 jdhunter@bic128:mpl98.5> grep backend_agg.cpp sdist.out
 copying src/_backend_agg.cpp -> matplotlib-0.98.5.1/src
 copying src/backend_agg.cpp -> matplotlib-0.98.5.1/src
When I run easy_install on the src tarball, I then get::
 Installed /home/jdhunter/devez/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5-linux-x86_64.egg
 Processing dependencies for matplotlib==0.98.5.1
 Finished processing dependencies for matplotlib==0.98.5.1
 Exception exceptions.OSError: (2, 'No such file or directory',
'src/image.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x29bb440>> ignored
 Exception exceptions.OSError: (2, 'No such file or directory',
'src/path.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x29ba8c0>> ignored
 Exception exceptions.OSError: (2, 'No such file or directory',
'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x7fe8fa2ee998>> ignored
 Exception exceptions.OSError: (2, 'No such file or directory',
'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x29bb290>> ignored
Using the standard distutils with python 2.5.1

Angus McMorland wrote:
> Hi Mike et al,
>
> Thanks for the reply.
>
> 2008年12月15日 Michael Droettboom <md...@st...>:
> 
>> You don't need the $. In fact, an unescaped $ in a math expression is a
>> syntax error.
>>
>> Admittedly, the feedback about this could be better than just "couldn't
>> render". I'll look at passing more information about the exception back to
>> Sphinx.
>>
>> Note also, you'll want a slash in front of \alpha in order to get Greek,
>> rather than "alpha".
>> 
>
> I think I've copied the usage suggested by the 'writing mathtext' page
> in the mpl documentation (i.e. looking at its rst source [1]). That is
> to say, the appearance of $ and the lack of \ are produced by the
> extension, and not by me.
> 
I see what you're saying now. Sorry for the assumption.
> With this docstring:
>
> """
> Test docstring with :math:`\alpha`
>
> and longer
>
> .. math::
>
> \alpha = 2
>
> """
> 
You'll need to use raw strings (prefix the """ with an r) so that the \a 
will appear in the final string.
> I get this error:
>
> writing output... index modules/calculate
> /usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
> Warning: Could not render math expression $lpha$
> Warning)
> /usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
> Warning: Could not render math expression $lpha = 2$
> Warning)
>
> I've just redownloaded the sphinx extensions from matplotlib svn, so
> they're definitely all the latest versions.
> 
That doesn't seem to be the root of this problem, however, as these strings should at least render to *something*, though probably not what you want.
The warning is hiding the real error here. In mathmpl.py, after the line where the warning is emitted:
 warnings.warn("Could not render math expression %s" % latex,
 Warning)
Add the line:
 raise
and then post the output to this list?
Thanks,
Mike
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Dear John,
2008年12月15日 John Hunter <jd...@gm...>:
>
> I believe I have a workaround for this problem. Could you please test with
>
> easy_install http://matplotlib.sourceforge.net/snapshots/matplotlib-0.98.5.1.tar.gz
It worked well and MPL 0.98.5.1 has been successfully installed.
> There is some detritus at the end about "unable to remove
> suchandsuch.cpp" but this appears to be an unrelated distutils bug
> that is non-harmful but I am looking into.
In the end, I got the following messages:
Finished processing dependencies for matplotlib==0.98.5.1
Exception exceptions.OSError: (2, 'No such file or directory',
'src/image.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x874accc>> ignored
Exception exceptions.OSError: (2, 'No such file or directory',
'src/path.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x874a90c>> ignored
Exception exceptions.OSError: (2, 'No such file or directory',
'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x8881bec>> ignored
Exception exceptions.OSError: (2, 'No such file or directory',
'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of
<setupext.CleanUpFile instance at 0x874ab2c>> ignored
But everthing seems to be working OK, as I tested my application with
the newly installed version and it runs without crashes.
Thanks **a lot**!!!!
With warmest regards,
-- 
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: mau...@gm...
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."

Yeah -- certain cases probably have better type safety than others. 
Long term, we probably want to do more type checking closer to the entry 
points (rather than deeper where they actually cause exceptions but are 
at that point long-removed from the user error). That kind of checking 
doesn't seem to be the norm in languages like Python... but matplotlib 
is an exception in that it is more tuned to interactive use than many 
libraries.
Mauro Cavalcanti wrote:
> Dear Michael,
>
> Just noticed another quite interesting thing: if I (mistakenly) pass
> the "linewidth" parameter as a string (as I was doing previously with
> the "markersize" one), no backend error occurs!
>
> 2008年12月15日 Michael Droettboom <md...@st...>:
> 
>> Can you share the code you used to set the properties of points and lines.
>> It looks like somehow a string is being set where a floating-point value is
>> expected (either for dpi or markersize).
>>
>> Mike
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>> 
>
> I feel highly honoured and still happier by having someone from STSI
> helping me with my biodiversity mapping project. I appreciate a lot
> the STSI Python for interactive data analysis tutorial written by
> Perry Greenfield and Robert Jedrzejewki, I have found it very useful!)
>
> 
Thanks. I'll let them know. I feel highly honored to work with those 
folks, too... ;)
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Dec 15, 2008 at 2:21 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> "John Hunter" <jd...@gm...> writes:
>
>>> I'll take a closer look at this later.
>>
>> Thanks for looking into this Jouni -- please make sure to fix in the
>> branch and merge to the trunk, as described in
>> http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
>
> I have a patch (attached) that fixes this case but breaks figimage. It
> seems to me that the bug is in figimage, but with the current pdf
> backend (which forces dpi=72 for all images) it happens to work right.
> I'm a little wary of making this change on the maintenance branch
> without also fixing figimage, and I don't really know how to fix
> figimage.
>
> The bug in the pdf backend is that it forces dpi=72, because in PDF 1.4
> there are always 72 points to an inch. (In some later versions the scale
> can be changed, but never mind that for now.) This is a problem because
> sometimes people want to have their figures at a higher resolution. The
> attached patch adds an image_dpi variable to the pdf backend and uses it
> like the ps backend does: get_image_magnification() returns
> image_dpi/72.0, and the width and height of images are divided by this
> magnification factor.
I am not sure what figimage should mean for a vector backend so I want
to hear from Perry who motivated the function. When I implemented it
on his original request, I understood it to be a raw pixel dump to the
canvas with no scaling, no interpolation, etc.... What does a pixel
dump to a canvas mean for a vector backend? I think we could define
something that was at least consistent, but we should probably hear
from Perry et al who are presumably using the function.
JDH

Hi Mike et al,
Thanks for the reply.
2008年12月15日 Michael Droettboom <md...@st...>:
> You don't need the $. In fact, an unescaped $ in a math expression is a
> syntax error.
>
> Admittedly, the feedback about this could be better than just "couldn't
> render". I'll look at passing more information about the exception back to
> Sphinx.
>
> Note also, you'll want a slash in front of \alpha in order to get Greek,
> rather than "alpha".
I think I've copied the usage suggested by the 'writing mathtext' page
in the mpl documentation (i.e. looking at its rst source [1]). That is
to say, the appearance of $ and the lack of \ are produced by the
extension, and not by me.
With this docstring:
 """
 Test docstring with :math:`\alpha`
 and longer
 .. math::
 \alpha = 2
 """
I get this error:
writing output... index modules/calculate
/usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
Warning: Could not render math expression $lpha$
 Warning)
/usr/lib/python2.5/site-packages/sphinx/ext/sphinxext/mathmpl.py:107:
Warning: Could not render math expression $lpha = 2$
 Warning)
I've just redownloaded the sphinx extensions from matplotlib svn, so
they're definitely all the latest versions.
[1] http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/users/mathtext.rst?view=markup
Thanks for any pointers.
Angus.
-- 
AJC McMorland
Post-doctoral research fellow
Neurobiology, University of Pittsburgh

"John Hunter" <jd...@gm...> writes:
>> I'll take a closer look at this later.
>
> Thanks for looking into this Jouni -- please make sure to fix in the
> branch and merge to the trunk, as described in
> http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
I have a patch (attached) that fixes this case but breaks figimage. It
seems to me that the bug is in figimage, but with the current pdf
backend (which forces dpi=72 for all images) it happens to work right.
I'm a little wary of making this change on the maintenance branch
without also fixing figimage, and I don't really know how to fix
figimage.
The bug in the pdf backend is that it forces dpi=72, because in PDF 1.4
there are always 72 points to an inch. (In some later versions the scale
can be changed, but never mind that for now.) This is a problem because
sometimes people want to have their figures at a higher resolution. The
attached patch adds an image_dpi variable to the pdf backend and uses it
like the ps backend does: get_image_magnification() returns
image_dpi/72.0, and the width and height of images are divided by this
magnification factor.
The problem with figimage is that it doesn't use the magnification
factor at all, so when it calls draw_image, the image as drawn by the
backend is scaled wrong. See also the following comment in image.py
(class FigureImage):
 2798 nnemec def make_image(self, magnification=1.0):
 2904 efiring # had to introduce argument magnification to satisfy the unit test
 2904 efiring # figimage_demo.py. I have no idea, how magnification should be used
 5883 jdh2358 # within the function. It should be !=1.0 only for non-default DPI<
 2904 efiring # settings in the PS backend, as introduced by patch #1562394
 2904 efiring # Probably Nicholas Young should look over this code and see, how
 2904 efiring # magnification should be handled correctly.
(When I say that this patch "breaks" figimage, I mean that before the
patch the pdf output of figimage_demo.py looks similar to the Agg
output, but after applying the patch it looks different.)
Ideas, anyone?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Can you share the code you used to set the properties of points and 
lines. It looks like somehow a string is being set where a 
floating-point value is expected (either for dpi or markersize).
Mike
Mauro Cavalcanti wrote:
> Dear ALL,
>
> When attempting to set the properties of points or lines in MPL 0.98.4
> using the wxAgg backend (which should display a Basemap, that does not
> appear because of the error) I am getting the following error -- it
> happens no matter how I set the properties, if using keyword arguments
> or the set methods:
>
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
> line 1122, in _onPaint
> self.draw(drawDC=drawDC)
> File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wxagg.py",
> line 60, in draw
> FigureCanvasAgg.draw(self)
> File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> line 283, in draw
> self.figure.draw(self.renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> 772, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1601, in draw
> a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 462, in draw
> markerFunc(renderer, gc, tpath, affine.frozen())
> File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line
> 794, in _draw_circle
> w = renderer.points_to_pixels(self._markersize) * 0.5
> File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> line 216, in points_to_pixels
> return points*self.dpi/72.0
> TypeError: unsupported operand type(s) for /: 'str' and 'float'
>
> Any hints?
>
> Best regards,
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Dear ALL,
When attempting to set the properties of points or lines in MPL 0.98.4
using the wxAgg backend (which should display a Basemap, that does not
appear because of the error) I am getting the following error -- it
happens no matter how I set the properties, if using keyword arguments
or the set methods:
Traceback (most recent call last):
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 1122, in _onPaint
 self.draw(drawDC=drawDC)
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wxagg.py",
line 60, in draw
 FigureCanvasAgg.draw(self)
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 283, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
772, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1601, in draw
 a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 462, in draw
 markerFunc(renderer, gc, tpath, affine.frozen())
 File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line
794, in _draw_circle
 w = renderer.points_to_pixels(self._markersize) * 0.5
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 216, in points_to_pixels
 return points*self.dpi/72.0
TypeError: unsupported operand type(s) for /: 'str' and 'float'
Any hints?
Best regards,
-- 
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: mau...@gm...
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."

Thanks.
I understood the explanation you gave me...was not so sure how it translated
in the language...
so what i did is creating a init_plot method...that is creating a figure
once and for all (empty) , attaching it to a canvas and pack it...
then I have my showplot routine activated by the button with contains only
the formula for X,Y, the plot statement and the show()
statement...and it worked!
now the plot window is correctly updated and ram usage is stable.
Thanks for the help!
I willl dig deepert o understand this better...
-- 
View this message in context: http://www.nabble.com/Correct-usage-of-Mpl-backend...-tp21012938p21020254.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

In the meantime, I was able to get everything working and could confirm.
Passing solid_joinstyle='bevel' does resolve the problem on both 0.91.x 
and 0.98.x. Additionally, path simplification (which is a new feature 
on 0.98.x) also resolves this problem (set rcParam path.simplify to True).
The wider question is:
 a) should bevel be the default going forward?
 b) maybe this deserves a FAQ entry
Mike
Jesse Berwald wrote:
> I compiled the code with following:
>
> gcc -o testode.o testode.c -lm -lgsl -lgslcblas
>
> I'm using gsl 1.10. Hope that helps. I'll try out the kwarg suggestions asap.
>
> Thanks for the help,
> -Jesse
>
> On Mon, Dec 15, 2008 at 9:38 AM, Michael Droettboom <md...@st...> wrote:
> 
>> I'm having trouble getting your C code to compile (maybe a gsl version
>> mismatch...?)
>>
>> In the meantime, perhaps you could try something for me.
>>
>> If you add the kwarg "solid_joinstyle='bevel'" or "solid_joinstyle='round'"
>> to your plot command, does that improve things? If so, we could consider
>> changing the default.
>>
>> Cheers,
>> Mike
>>
>> mtcoder wrote:
>> 
>>> All,
>>> Thanks for the quick and informative responses. I've attached the code
>>> (testode.c). It requires the GSL library. I've also attached the script I
>>> was using to read and plot the data (odetest.py). [Note: If you do any
>>> tests
>>> with the python script make sure to change the savefig directory in plot()
>>> to something local. ]
>>>
>>> http://www.nabble.com/file/p20996825/testode.zip testode.zip test code
>>>
>>> John: I'm using evince to view pdf's (but acroread produces the same
>>> behavior as Michael's attachments showed).
>>> Michael: I changed the backend to Cairo and saved the figures directly to
>>> pdf. Same results. To be clear, to do this I changed the matplotlibrc file
>>> (backend GTKAgg -> Cairo) and then changed the filename in savefig to end
>>> with ".pdf". I assume that is what you had in mind.
>>> In addition, as requested here are two screenshots in png format of the
>>> actual pylab/matplotlib output:
>>>
>>> http://www.nabble.com/file/p20996825/odetest_pylabimg.png
>>> odetest_pylabimg.png output
>>> http://www.nabble.com/file/p20996825/odetest_pylabimg_zoom.png
>>> odetest_pylabimg_zoom.png output zoomed.
>>> Thanks for the help,
>>> -Jesse
>>>
>>>
>>> Michael Droettboom-3 wrote:
>>>
>>> 
>>>> Also -- for mtcoder:
>>>>
>>>> Can you send us the script that generates your plot?
>>>>
>>>> Also, if you set your backend to Cairo, and then generate the pdf, to you
>>>> get the same result?
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Michael Droettboom wrote:
>>>>
>>>> 
>>>>> There's something funny going on with line caps, maybe? It looks like
>>>>> the corners aren't getting capped in the same way as Agg does.
>>>>>
>>>>> I've created screenshots of Jesse's pdf file in acrobat and evince.
>>>>>
>>>>> Any thought, Jouni?
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>> John Hunter wrote:
>>>>>
>>>>> 
>>>>>> On Thu, Dec 11, 2008 at 11:16 PM, mtcoder <jbe...@gm...> wrote:
>>>>>>
>>>>>>
>>>>>> 
>>>>>>> http://www.nabble.com/file/p20970084/testode.rk45.a0.99.eps1e-07.pdf
>>>>>>> testode.rk45.a0.99.eps1e-07.pdf . This comes from a completely
>>>>>>> deterministic
>>>>>>> ode. But is looks like I've added a tiny amount of noise.
>>>>>>>
>>>>>>> On a technical note, I'm running Ubuntu 8.04, python2.5.1,
>>>>>>> matplotlib0.91.2
>>>>>>> (with GTKAgg backend).
>>>>>>>
>>>>>>> (Hopefully I didn't miss a similar question--and solution--elsewhere
>>>>>>> in the
>>>>>>> forum.)
>>>>>>>
>>>>>>> 
>>>>>> My guess is that you may be seeing the antialiasing of your pdf
>>>>>> renderer. matplotlib has a pretty good antialiasing renderer for the
>>>>>> screen display (antigrain) but your mileage may vary for your pdf
>>>>>> renderer. Since pdf is a vector output, we have no control over the
>>>>>> renderering. What pdf viewer are you using? The best way for us to
>>>>>> see what you are seeing is to take a PNG screenshot of your PDF file
>>>>>> displayed in your viewer and then post the PNG. Ie, here is what I am
>>>>>> seeing in the Preview app: the fuzziness is from the antialiasing, but
>>>>>> I am used to seeing this.
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>>>>> Nevada.
>>>>>> The future of the web can't happen without you. Join us at MIX09 to
>>>>>> help
>>>>>> pave the way to the Next Web now. Learn more and register at
>>>>>>
>>>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>
>>>>>> 
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>>>> Nevada.
>>>>> The future of the web can't happen without you. Join us at MIX09 to
>>>>> help
>>>>> pave the way to the Next Web now. Learn more and register at
>>>>>
>>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>> 
>>>> ------------------------------------------------------------------------------
>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>>> Nevada.
>>>> The future of the web can't happen without you. Join us at MIX09 to help
>>>> pave the way to the Next Web now. Learn more and register at
>>>>
>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>>
>>>> 
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 
>
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I compiled the code with following:
gcc -o testode.o testode.c -lm -lgsl -lgslcblas
I'm using gsl 1.10. Hope that helps. I'll try out the kwarg suggestions asap.
Thanks for the help,
-Jesse
On Mon, Dec 15, 2008 at 9:38 AM, Michael Droettboom <md...@st...> wrote:
> I'm having trouble getting your C code to compile (maybe a gsl version
> mismatch...?)
>
> In the meantime, perhaps you could try something for me.
>
> If you add the kwarg "solid_joinstyle='bevel'" or "solid_joinstyle='round'"
> to your plot command, does that improve things? If so, we could consider
> changing the default.
>
> Cheers,
> Mike
>
> mtcoder wrote:
>>
>> All,
>> Thanks for the quick and informative responses. I've attached the code
>> (testode.c). It requires the GSL library. I've also attached the script I
>> was using to read and plot the data (odetest.py). [Note: If you do any
>> tests
>> with the python script make sure to change the savefig directory in plot()
>> to something local. ]
>>
>> http://www.nabble.com/file/p20996825/testode.zip testode.zip test code
>>
>> John: I'm using evince to view pdf's (but acroread produces the same
>> behavior as Michael's attachments showed).
>> Michael: I changed the backend to Cairo and saved the figures directly to
>> pdf. Same results. To be clear, to do this I changed the matplotlibrc file
>> (backend GTKAgg -> Cairo) and then changed the filename in savefig to end
>> with ".pdf". I assume that is what you had in mind.
>> In addition, as requested here are two screenshots in png format of the
>> actual pylab/matplotlib output:
>>
>> http://www.nabble.com/file/p20996825/odetest_pylabimg.png
>> odetest_pylabimg.png output
>> http://www.nabble.com/file/p20996825/odetest_pylabimg_zoom.png
>> odetest_pylabimg_zoom.png output zoomed.
>> Thanks for the help,
>> -Jesse
>>
>>
>> Michael Droettboom-3 wrote:
>>
>>>
>>> Also -- for mtcoder:
>>>
>>> Can you send us the script that generates your plot?
>>>
>>> Also, if you set your backend to Cairo, and then generate the pdf, to you
>>> get the same result?
>>>
>>> Cheers,
>>> Mike
>>>
>>> Michael Droettboom wrote:
>>>
>>>>
>>>> There's something funny going on with line caps, maybe? It looks like
>>>> the corners aren't getting capped in the same way as Agg does.
>>>>
>>>> I've created screenshots of Jesse's pdf file in acrobat and evince.
>>>>
>>>> Any thought, Jouni?
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> John Hunter wrote:
>>>>
>>>>>
>>>>> On Thu, Dec 11, 2008 at 11:16 PM, mtcoder <jbe...@gm...> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> http://www.nabble.com/file/p20970084/testode.rk45.a0.99.eps1e-07.pdf
>>>>>> testode.rk45.a0.99.eps1e-07.pdf . This comes from a completely
>>>>>> deterministic
>>>>>> ode. But is looks like I've added a tiny amount of noise.
>>>>>>
>>>>>> On a technical note, I'm running Ubuntu 8.04, python2.5.1,
>>>>>> matplotlib0.91.2
>>>>>> (with GTKAgg backend).
>>>>>>
>>>>>> (Hopefully I didn't miss a similar question--and solution--elsewhere
>>>>>> in the
>>>>>> forum.)
>>>>>>
>>>>>
>>>>> My guess is that you may be seeing the antialiasing of your pdf
>>>>> renderer. matplotlib has a pretty good antialiasing renderer for the
>>>>> screen display (antigrain) but your mileage may vary for your pdf
>>>>> renderer. Since pdf is a vector output, we have no control over the
>>>>> renderering. What pdf viewer are you using? The best way for us to
>>>>> see what you are seeing is to take a PNG screenshot of your PDF file
>>>>> displayed in your viewer and then post the PNG. Ie, here is what I am
>>>>> seeing in the Preview app: the fuzziness is from the antialiasing, but
>>>>> I am used to seeing this.
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>>>> Nevada.
>>>>> The future of the web can't happen without you. Join us at MIX09 to
>>>>> help
>>>>> pave the way to the Next Web now. Learn more and register at
>>>>>
>>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>>> Nevada.
>>>> The future of the web can't happen without you. Join us at MIX09 to
>>>> help
>>>> pave the way to the Next Web now. Learn more and register at
>>>>
>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>> Nevada.
>>> The future of the web can't happen without you. Join us at MIX09 to help
>>> pave the way to the Next Web now. Learn more and register at
>>>
>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
PhD Candidate
Department of Mathematics
Montana State University
Bozeman, MT

On Mon, Dec 15, 2008 at 12:22 PM, Alejandro Weinstein
<ale...@gm...> wrote:
> Hi:
>
> Is anybody aware of the MPL bug on Ubuntu intrepid?
>
> https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/299381
>
Thanks for the head's up -- I posted a comment with a suggestion about
what may be going on.
JDH

Hi:
Is anybody aware of the MPL bug on Ubuntu intrepid?
https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/299381
Basically you get a warning when import pylab. Beside the warnings
things seems to work OK.
Is there a workaround for this?
Regards,
Alejandro.

On Mon, Dec 15, 2008 at 11:04 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> The (812 pixels high) image has been embedded in a png of height 617,
> but in the pdf file it has height 446. 446/617 is about .72, so the
> problem must be that the pdf backend forces the dpi to 72, while the png
> file is being saved with dpi=100. There is a TODO comment in the pdf
> backend about figure resolution that I added in February but never got
> around to fixing. I'll take a closer look at this later.
Thanks for looking into this Jouni -- please make sure to fix in the
branch and merge to the trunk, as described in
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge

On Mon, Dec 15, 2008 at 9:45 AM, Alexander Chemeris
<ale...@gm...> wrote:
> I experience the same problem. Full shell session (of one
> command ;) is following:
>
> ~$ sudo easy_install matplotlib
> Searching for matplotlib
> Reading http://pypi.python.org/simple/matplotlib/
> Reading http://matplotlib.sourceforge.net
> Reading
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> Reading
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
> Best match: matplotlib 0.98.5
> Downloading
> http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0
> Processing matplotlib-0.98.5.tar.gz
> Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-fpPLdN/matplotlib-0.98.5/egg-dist-tmp-0LZ25S
> ...snip
> error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or
> directory
> Exception exceptions.OSError: (2, 'No such file or directory',
> 'src/image.cpp') in <bound method CleanUpFile.__del__ of
> <setupext.CleanUpFile instance at 0x2fd7d40>> ignored
> Exception exceptions.OSError: (2, 'No such file or directory',
> 'src/path.cpp') in <bound method CleanUpFile.__del__ of
> <setupext.CleanUpFile instance at 0x2fd7200>> ignored
> Exception exceptions.OSError: (2, 'No such file or directory',
> 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of
> <setupext.CleanUpFile instance at 0x2fd7b90>> ignored
I can replicate it too, and I think I am getting some insight into
what is going on and it may point to a distutils and/or easy_install
bug (but one we can work around).
The file in question is matplotlib.conf.template, which exists in
lib/matplotlib/mpl-data. There is a symlink in doc/mpl_data which
points to lib/matplotlib/mpl-data. Eg in the mpl src tree::
 jdhunter@bic128:mpl> ls -ld lib/matplotlib/mpl-data/ doc/mpl_data
 lrwxrwxrwx 1 jdhunter jdhunter 27 Jun 2 2008 doc/mpl_data ->
../lib/matplotlib/mpl-data/
 drwxrwxr-x 6 jdhunter jdhunter 4096 Dec 10 13:09 lib/matplotlib/mpl-data/
Now create the sdist::
 jdhunter@bic128:mpl> python setup.py sdist > sdist.out
 jdhunter@bic128:mpl> grep matplotlib.conf.template sdist.out
 hard linking doc/mpl_data/matplotlib.conf.template ->
matplotlib-0.98.5/doc/mpl_data
 hard linking lib/matplotlib/mpl-data/matplotlib.conf.template ->
matplotlib-0.98.5/lib/matplotlib/mpl-data
If we create an sdist, the symlink is backwards: the tarball says
lib/matplotlib/mpl-data/matplotlib.conf.template links to
doc/mpl_data/matplotlib.conf.template and has zero content
 jdhunter@bic128:tmp> tar tvfz matplotlib-0.98.5.tar.gz |grep
matplotlib.conf.template
 -rw-r--r-- cmoad/staff 13838 2008年12月09日 17:53
matplotlib-0.98.5/doc/mpl_data/matplotlib.conf.templatehrw-r--r--
cmoad/staff 0 2008年12月09日 17:53
matplotlib-0.98.5/lib/matplotlib/mpl-data/matplotlib.conf.template
link to matplotlib-0.98.5/doc/mpl_data/matplotlib.conf.template
If you unpack the tarball using a standard incantation, a copy is made::
 jdhunter@bic128:tmp> tar xfz matplotlib-0.98.5.tar.gz
 jdhunter@bic128:tmp> cd matplotlib-0.98.5/
 jdhunter@bic128:matplotlib-0.98.5> ls -ld
doc/mpl_data/matplotlib.conf.template
lib/matplotlib/mpl-data/matplotlib.conf.template
 -rw-r--r-- 2 jdhunter jdhunter 13838 Dec 9 17:53
doc/mpl_data/matplotlib.conf.template
 -rw-r--r-- 2 jdhunter jdhunter 13838 Dec 9 17:53
lib/matplotlib/mpl-data/matplotlib.conf.template
I think what may be happening is that setuptools are reading the
tarball using the python tarfile reader and the link is getting
botched. However, I can read the "missing" file using tarfile::
 In [17]: import tarfile
 In [18]: t = tarfile.open('dist/matplotlib-0.98.5.tar.gz')
 In [19]: o =
t.extractfile('matplotlib-0.98.5/lib/matplotlib/mpl-data/matplotlib.conf')
 In [20]: s = o.read()
 In [21]: print s[:80]
 # MPLConfig - plaintext (in .conf format)
 # This is a sample matplotlib configu
So I am not sure exactly what is going wrong but I think broken
handling of the link is playing a role. I will probably work around
this by removing the links and making hard copies myself before
building the sdist and eggs, unless I hear something more intelligent
from someone or come up with something better.

You don't need the $. In fact, an unescaped $ in a math expression is a 
syntax error.
Admittedly, the feedback about this could be better than just "couldn't 
render". I'll look at passing more information about the exception back 
to Sphinx.
Note also, you'll want a slash in front of \alpha in order to get Greek, 
rather than "alpha".
Mike
Angus McMorland wrote:
> Hi guys,
>
> I'm trying to use sphinx and your mathmpl extension to document some
> of my own code, but I'm getting an error saying, in the simplest
> instance:
>
> Warning: Could not render math expression $alpha$
>
> Is mathmpl dependent on a particular version of sphinx? I'm using
> 0.4.2-1 from debian at the moment. If that's not the problem, any idea
> what else could be going wrong?
>
> Thanks,
>
> Angus.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom <md...@st...> writes:
> Keep in mind that we can't control the kind of interpolation used by
> the PDF viewer. I don't know if that is what you're seeing.
I think the problem is with image dpi: 
% identify maize_raw.jpg 
maize_raw.jpg JPEG 400x812 400x812+0+0 DirectClass 8-bit 56.2012kb
% identify maize.png
maize.png PNG 617x617 617x617+0+0 DirectClass 8-bit 297.305kb
% grep Width maize.pdf 
<< /Width 220 /ColorSpace /DeviceGray /Height 446 /Subtype /Image
<< /SMask 13 0 R /Width 220 /ColorSpace /DeviceRGB /Height 446
The (812 pixels high) image has been embedded in a png of height 617,
but in the pdf file it has height 446. 446/617 is about .72, so the
problem must be that the pdf backend forces the dpi to 72, while the png
file is being saved with dpi=100. There is a TODO comment in the pdf
backend about figure resolution that I added in February but never got
around to fixing. I'll take a closer look at this later.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"Haibao Tang" <tan...@gm...> writes:
> However, the following issue is still there. In the following script, I try
> to display an image in a pdf. This would run. Now please change the
> maize.pdf to maize.png and generate yet another file. Zoom and look closely
> at the two files generated. You see that the pdf quality is substantially
> lower than the png.
I can reproduce this; it looks like I introduced this bug in revision
4933, which was necessary to fix another problem, and never got back to
fixing the problem that the change caused with image resolution. I'll
look into this tonight (Finnish time). Thanks for the report!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi guys,
I'm trying to use sphinx and your mathmpl extension to document some
of my own code, but I'm getting an error saying, in the simplest
instance:
Warning: Could not render math expression $alpha$
Is mathmpl dependent on a particular version of sphinx? I'm using
0.4.2-1 from debian at the moment. If that's not the problem, any idea
what else could be going wrong?
Thanks,
Angus.
-- 
AJC McMorland
Post-doctoral research fellow
Neurobiology, University of Pittsburgh

I'm having trouble getting your C code to compile (maybe a gsl version 
mismatch...?)
In the meantime, perhaps you could try something for me.
If you add the kwarg "solid_joinstyle='bevel'" or 
"solid_joinstyle='round'" to your plot command, does that improve 
things? If so, we could consider changing the default.
Cheers,
Mike
mtcoder wrote:
> All, 
>
> Thanks for the quick and informative responses. I've attached the code
> (testode.c). It requires the GSL library. I've also attached the script I
> was using to read and plot the data (odetest.py). [Note: If you do any tests
> with the python script make sure to change the savefig directory in plot()
> to something local. ]
>
> http://www.nabble.com/file/p20996825/testode.zip testode.zip test code
>
> John: I'm using evince to view pdf's (but acroread produces the same
> behavior as Michael's attachments showed). 
>
> Michael: I changed the backend to Cairo and saved the figures directly to
> pdf. Same results. To be clear, to do this I changed the matplotlibrc file
> (backend GTKAgg -> Cairo) and then changed the filename in savefig to end
> with ".pdf". I assume that is what you had in mind. 
>
> In addition, as requested here are two screenshots in png format of the
> actual pylab/matplotlib output:
>
> http://www.nabble.com/file/p20996825/odetest_pylabimg.png
> odetest_pylabimg.png output
> http://www.nabble.com/file/p20996825/odetest_pylabimg_zoom.png
> odetest_pylabimg_zoom.png output zoomed. 
>
> Thanks for the help,
> -Jesse
>
>
> Michael Droettboom-3 wrote:
> 
>> Also -- for mtcoder:
>>
>> Can you send us the script that generates your plot?
>>
>> Also, if you set your backend to Cairo, and then generate the pdf, to 
>> you get the same result?
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> There's something funny going on with line caps, maybe? It looks like 
>>> the corners aren't getting capped in the same way as Agg does.
>>>
>>> I've created screenshots of Jesse's pdf file in acrobat and evince.
>>>
>>> Any thought, Jouni?
>>>
>>> Cheers,
>>> Mike
>>>
>>> John Hunter wrote:
>>> 
>>>> On Thu, Dec 11, 2008 at 11:16 PM, mtcoder <jbe...@gm...> wrote:
>>>>
>>>> 
>>>> 
>>>>> http://www.nabble.com/file/p20970084/testode.rk45.a0.99.eps1e-07.pdf
>>>>> testode.rk45.a0.99.eps1e-07.pdf . This comes from a completely 
>>>>> deterministic
>>>>> ode. But is looks like I've added a tiny amount of noise.
>>>>>
>>>>> On a technical note, I'm running Ubuntu 8.04, python2.5.1, 
>>>>> matplotlib0.91.2
>>>>> (with GTKAgg backend).
>>>>>
>>>>> (Hopefully I didn't miss a similar question--and solution--elsewhere 
>>>>> in the
>>>>> forum.)
>>>>> 
>>>>> 
>>>> My guess is that you may be seeing the antialiasing of your pdf
>>>> renderer. matplotlib has a pretty good antialiasing renderer for the
>>>> screen display (antigrain) but your mileage may vary for your pdf
>>>> renderer. Since pdf is a vector output, we have no control over the
>>>> renderering. What pdf viewer are you using? The best way for us to
>>>> see what you are seeing is to take a PNG screenshot of your PDF file
>>>> displayed in your viewer and then post the PNG. Ie, here is what I am
>>>> seeing in the Preview app: the fuzziness is from the antialiasing, but
>>>> I am used to seeing this.
>>>> 
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, 
>>>> Nevada.
>>>> The future of the web can't happen without you. Join us at MIX09 to 
>>>> help
>>>> pave the way to the Next Web now. Learn more and register at
>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ 
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>> 
>>>> 
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>>> Nevada.
>>> The future of the web can't happen without you. Join us at MIX09 to help
>>> pave the way to the Next Web now. Learn more and register at
>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>> 
>>> 
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>> Nevada.
>> The future of the web can't happen without you. Join us at MIX09 to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Keep in mind that we can't control the kind of interpolation used by the 
PDF viewer. I don't know if that is what you're seeing.
I'm not seeing a loss in quality in PDF. I do, however, see a different 
color profile being applied by acroread (making the corn husk appear 
darker). matplotlib is completely ignorant of any sort of icc profiles 
etc., so it's possible it's doing the wrong thing in that regard. It 
also could be that acroread is one of the few applications on my Linux 
box that cares about color profiles at all, and it is "right" when 
everything else is "wrong".
Is the difference seen in my attached screenshot what you're referring 
to, or are you seeing something worse? What pdf viewer are you using? 
Are you using the Cairo backend?
Mike
Haibao Tang wrote:
> I have raised two issues on imshow with pdf backend weeks ago since 
> the upgrade from 0.91 to 0.98. I am happy to see one of them already 
> fixed.
>
> However, the following issue is still there. In the following script, 
> I try to display an image in a pdf. This would run. Now please change 
> the maize.pdf to maize.png and generate yet another file. Zoom and 
> look closely at the two files generated. You see that the pdf quality 
> is substantially lower than the png.
>
> I wonder if anyone would reproduce it and ... any way to solve it.
>
> -----------------------------------------------------------
> from matplotlib.pyplot import *
> from urllib import urlretrieve
>
> figure(1,(6,6))
> root = axes([0,0,1,1])
>
> urlretrieve("http://www.alexandrajones.co.uk/images/large/maize.jpg","maize_raw.jpg")
> img = imread("maize_raw.jpg")
> root.imshow(img)
>
> root.set_axis_off()
> savefig("maize.pdf")
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Dec 15, 2008 at 9:44 AM, John Hunter <jd...@gm...> wrote:
> By default matplotlib overplots, so every time you call plot a new
> line is added to the canvas. You can turn this behavior off using the
> hold method
Sorry, on second look it appears you have a more serious problem.
Typically you want to create your figure and canvas just once and add
it to your GUI. And then when the user clicks plot, just draw to the
existing axes
def __init__():
 self.figure = some code
 self.canvas = some code
 self.axes = some code
def onclick(self):
 self.axes.cla() # clear if you want
 self.axes.plot(something)
Ie, you want to reuse the same figure/canvas/axes instead of
recreating them all the time