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
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 <ol...@fy...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
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
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
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 > >
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
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