matplotlib-devel Mailing List for matplotlib

I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.
Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?
Thanks,
Eric
Sample code to reproduce the problem:
import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')

On 2009年2月19日, Michael Droettboom wrote:
> The drawing and then clipping is normal behavior. All of the backend formats 
> have the ability to clip out arbitrary regions for drawing, so we take 
> advantage of that rather than doing our own geometric clipping algorithm. 
> The latter is a great deal of work to get right.
>
> It sounds like the Inkscape PDF export is not exporting the clipping path 
> correctly, which may actually be related to the version of Cairo Inkscape is 
> using. In any case, there's not much we can do here.
I see, thanks for explaining.
This is actually the Inkscape bug 
https://bugs.launchpad.net/inkscape/+bug/168800 with one of the comments 
suggesting to learn from Matplotlib how to export clipping to pdf with 
Cairo. It is supposedly fixed in Inkscape svn trunk.
/Olle

Olle Engdegård wrote:
>
> Sorry for not being clear enough.
>
> I see this only when exporting to svg, importing it to Inkscape and 
> then saving as pdf there. Never interactively. And never if exporting 
> directly to pdf from matplotlib.
>
> It could very well be a bug in Inkscape, but matplotlib is still 
> saving data that should not be there, this is what I wanted to point out.
>
> And I take it back that it doesn't show in Inkscape, it was just 
> hidden from view. The extra bars are there.
You were clear -- it was just early in the morning for me here and my 
eyes to brain converter wasn't working properly ;)
The drawing and then clipping is normal behavior. All of the backend 
formats have the ability to clip out arbitrary regions for drawing, so 
we take advantage of that rather than doing our own geometric clipping 
algorithm. The latter is a great deal of work to get right.
It sounds like the Inkscape PDF export is not exporting the clipping 
path correctly, which may actually be related to the version of Cairo 
Inkscape is using. In any case, there's not much we can do here.
Mike

Sorry for not being clear enough.
I see this only when exporting to svg, importing it to Inkscape and then 
saving as pdf there. Never interactively. And never if exporting directly 
to pdf from matplotlib.
It could very well be a bug in Inkscape, but matplotlib is still saving 
data that should not be there, this is what I wanted to point out.
And I take it back that it doesn't show in Inkscape, it was just hidden 
from view. The extra bars are there.
/Olle
On 2009年2月19日, Michael Droettboom wrote:
> I take this back -- I hadn't read your initial bug very carefully.
>
> If Inkscape is rendering the SVG correctly, but it's PDF output is not 
> correct, then that seems like an Inkscape bug or a PDF viewer bug -- there's 
> not too much we could do on the matplotlib end.
>
> When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see it in 
> the interactive window, or just this behavior when you save an SVG, load it 
> in Inkscape and then output a PDF? In the latter case, the SVG output from 
> all backends (except Cairo) follows the same code path so should be 
> identical.
>
> Does directly outputting PDF from matplotlib work for you ? -- (it works 
> here)
>
> Mike
>
>
> Michael Droettboom wrote:
>> I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
>> further and see what I can determine.
>> 
>> Mike
>> 
>> Olle Engdegård wrote:
>> 
>>> On 2009年2月18日, Joshua Lippai wrote:
>>> 
>>>> Interesting. I can't reproduce your result using either the MacOSX or
>>>> WXAgg backend. Which backend are you using, and does the problem
>>>> persist if you use a different one?
>>>> 
>>> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>>> 
>>> /Olle
>>>
>>> 
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, 
>>> CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the 
>>> Enterprise
>>> -Strategies to boost innovation and cut costs with open source 
>>> participation
>>> -Receive a 600ドル discount off the registration fee with the source code: 
>>> SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> 
>>
>> 
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

I take this back -- I hadn't read your initial bug very carefully.
If Inkscape is rendering the SVG correctly, but it's PDF output is not 
correct, then that seems like an Inkscape bug or a PDF viewer bug -- 
there's not too much we could do on the matplotlib end.
When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see 
it in the interactive window, or just this behavior when you save an 
SVG, load it in Inkscape and then output a PDF? In the latter case, the 
SVG output from all backends (except Cairo) follows the same code path 
so should be identical.
Does directly outputting PDF from matplotlib work for you ? -- (it works 
here)
Mike
Michael Droettboom wrote:
> I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
> further and see what I can determine.
>
> Mike
>
> Olle Engdegård wrote:
> 
>> On 2009年2月18日, Joshua Lippai wrote:
>> 
>> 
>>> Interesting. I can't reproduce your result using either the MacOSX or
>>> WXAgg backend. Which backend are you using, and does the problem
>>> persist if you use a different one?
>>> 
>>> 
>> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>>
>> /Olle
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a 600ドル discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Feb 18, 2009 at 2:43 PM, James Evans <jre...@ea...> wrote:
> All,
>
> I have just submitted a first-cut at a unit-test harness. The unit-tests
> do require the use of the 'nose' python module.
> Everything has been placed in the 'test' directory off of the root trunk
> branch. There is a README file with lots of information on
> how to use it. This is in addition to a few test cases already bundled in
> (they make great examples)! The idea is that whenever
> somebody adds a new feature or makes a change they update/add the
> appropriate test case and re-run the harness to make sure nothing
> is broken.
>
> There is most definitely room for improvement with this, but it gives a
> starting point from which discussions and modifications can
> take place.
>
> Any questions or comments?
What is the naming convention for the test harness? I see
filenames_with_underscores, camelCase, CapWords, and it looks like all the
methods in MplTestCase are camelCase, whereas mpl uses only
names_with_underscores. Although it would probably be a lot of busy work to
convert at this point, I think it would be a good idea to follow the
existing mpl naming conventions.
Darren

I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
further and see what I can determine.
Mike
Olle Engdegård wrote:
> On 2009年2月18日, Joshua Lippai wrote:
> 
>> Interesting. I can't reproduce your result using either the MacOSX or
>> WXAgg backend. Which backend are you using, and does the problem
>> persist if you use a different one?
>> 
>
> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>
> /Olle
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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