Doing
from pylab import *
x=normal(10, size=1000)
hist(x)
xlim(0,10)
savefig("Image.svg")
and then importing the file to Inkscape and saving it there as a pdf gives the attached result. The stuff right of x=10 is suddenly there. The weirdest thing is that Inkscape _does not see this overspill_!
Not sure what is happening here, cannot reproduce it with plot() instead of hist().
Cheers,
Olle
Image.pdf (8.76 KB)
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?
Josh
On Wed, Feb 18, 2009 at 11:12 AM, Olle Engdegård <olle@...599...> wrote:
Doing
from pylab import *
x=normal(10, size=1000)
hist(x)
xlim(0,10)
savefig("Image.svg")and then importing the file to Inkscape and saving it there as a pdf gives
the attached result. The stuff right of x=10 is suddenly there. The weirdest
thing is that Inkscape _does not see this overspill_!Not sure what is happening here, cannot reproduce it with plot() instead of
hist().Cheers,
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Hmm, I see it in at least WXAgg, WX, GTKAgg ...
/Olle
On Wed, 18 Feb 2009, 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?
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 Wed, 18 Feb 2009, 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
Matplotlib-devel@lists.sourceforge.net
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 Wed, 18 Feb 2009, 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
Matplotlib-devel@lists.sourceforge.net
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
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 Thu, 19 Feb 2009, 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 Wed, 18 Feb 2009, 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
Matplotlib-devel@lists.sourceforge.net
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
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
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
On Thu, 19 Feb 2009, 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.