Not sure when this occurred, but I just updated to the latest SVN and
still see the issue:
I am no longer able to save transparent figure---specifically, I
need no patch drawn for the figure and axis when saving to EPS.
>>> savefig('test.eps', transparent=True)
The above should work, but it doesn't.. Explicitly setting the patch
colors to 'none' doesn't work either.
Anyone else seeing this?
Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.
Setting patch's (face) color to "none" work for me. If it does not
work, please post a complete script.
Regards,
-JJ
On Mon, Apr 26, 2010 at 2:38 AM, T J <tj...@gm...> wrote:
> Not sure when this occurred, but I just updated to the latest SVN and
> still see the issue:
> I am no longer able to save transparent figure---specifically, I
> need no patch drawn for the figure and axis when saving to EPS.
>
>>>> savefig('test.eps', transparent=True)
>
> The above should work, but it doesn't.. Explicitly setting the patch
> colors to 'none' doesn't work either.
>
> Anyone else seeing this?
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee...@gm...> wrote: > Looking at the code, the "transparent" option set alphas of paches to > 0, which I think is simply ignored in ps backend (which does not > support alpha). I think it is better if the visibility of patches is > set to False when the "transparent" option is set. > Or both. > Setting patch's (face) color to "none" work for me. If it does not > work, please post a complete script. > Attached. But I'm not doing anything fancy. I've also attached the EPS along with a TEX document.
On Mon, Apr 26, 2010 at 12:28 PM, T J <tj...@gm...> wrote: > On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee...@gm...> wrote: >> Looking at the code, the "transparent" option set alphas of paches to >> 0, which I think is simply ignored in ps backend (which does not >> support alpha). I think it is better if the visibility of patches is >> set to False when the "transparent" option is set. >> > > Attached. But I'm not doing anything fancy. I've also attached the > EPS along with a TEX document. > Has anyone been able to reproduce this? If not, it suggests a local problem for me. I am still interested in figuring it out, but I could use some pointers.
Jae-Joon Lee wrote:
> Looking at the code, the "transparent" option set alphas of paches to
> 0, which I think is simply ignored in ps backend (which does not
> support alpha). I think it is better if the visibility of patches is
> set to False when the "transparent" option is set.
The ps backend does not support alpha in general, but it does use
alpha=0 as a flag to not render. The problem is that there is a single
alpha for an artist with both line color and face color. The artist
alpha kwarg and attribute are at the root of much of the present
alpha-mess in mpl.
>
> Setting patch's (face) color to "none" work for me. If it does not
> work, please post a complete script.
I think this is what needs to be fixed in figure.py: the transparent
option should be manipulating the patch facecolors, not the patch artist
alpha value.
Eric
>
> Regards,
>
> -JJ
>
>
>
> On Mon, Apr 26, 2010 at 2:38 AM, T J <tj...@gm...> wrote:
>> Not sure when this occurred, but I just updated to the latest SVN and
>> still see the issue:
>> I am no longer able to save transparent figure---specifically, I
>> need no patch drawn for the figure and axis when saving to EPS.
>>
>>>>> savefig('test.eps', transparent=True)
>> The above should work, but it doesn't.. Explicitly setting the patch
>> colors to 'none' doesn't work either.
>>
>> Anyone else seeing this?
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
T J wrote: > On Mon, Apr 26, 2010 at 12:28 PM, T J <tj...@gm...> wrote: >> On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee...@gm...> wrote: >>> Looking at the code, the "transparent" option set alphas of paches to >>> 0, which I think is simply ignored in ps backend (which does not >>> support alpha). I think it is better if the visibility of patches is >>> set to False when the "transparent" option is set. >>> >> Attached. But I'm not doing anything fancy. I've also attached the >> EPS along with a TEX document. >> > > > Has anyone been able to reproduce this? If not, it suggests a local > problem for me. I am still interested in figuring it out, but I could > use some pointers. It's a bug, made more confusing by the trickery that is done when printing a figure. DPI, facecolor, and edgecolor that are set for a figure object are used only for screen display, and are overridden when the figure is saved. The overriding values can be supplied to the savefig call or via rcParams. I think I have fixed the bug in svn, so that "transparent" will work as advertised. In addition, I made a change so that even with transparent=True, if you supply facecolor and/or edgecolor to the savefig call, those values should be used for the figure patch when the figure is saved. This might be useful if you want to keep the line around the figure, for example. Eric
On Wed, Apr 28, 2010 at 12:22 PM, Eric Firing <ef...@ha...> wrote: > > It's a bug, made more confusing by the trickery that is done when printing a > figure. DPI, facecolor, and edgecolor that are set for a figure object are > used only for screen display, and are overridden when the figure is saved. > The overriding values can be supplied to the savefig call or via rcParams. > > I think I have fixed the bug in svn, so that "transparent" will work as > advertised. In addition, I made a change so that even with > transparent=True, if you supply facecolor and/or edgecolor to the savefig > call, those values should be used for the figure patch when the figure is > saved. This might be useful if you want to keep the line around the figure, > for example. > This still does not work for me. I dug around a bit and found an issue. Figure.savefig() sets the 'edgecolor' and 'facecolor' of the axis patches but delegates the patches of the figure to the actual print command. It does this by setting the edgecolor and facecolor values in the kwargs dict. However, self.canvas.print_figure() expects edgecolor and facecolor as args, not kwargs. So print_figure() uses the default value: 'w' instead of 'none'. This is a bit inconsistent, it seems, especially b/c the PS backend (which is called after print_figure()) expects facecolor and edgecolor as kwargs. I went ahead and changed this, hoping it'd fix the issue, but it does not. At least now, I can see that the edgecolor and facecolor are both set to 'none' all the way until self.figure.draw(renderer) is called. So somehow, the draw() command is unaffected by this still. What next?
T J wrote: > On Wed, Apr 28, 2010 at 12:22 PM, Eric Firing <ef...@ha...> wrote: >> It's a bug, made more confusing by the trickery that is done when printing a >> figure. DPI, facecolor, and edgecolor that are set for a figure object are >> used only for screen display, and are overridden when the figure is saved. >> The overriding values can be supplied to the savefig call or via rcParams. >> >> I think I have fixed the bug in svn, so that "transparent" will work as >> advertised. In addition, I made a change so that even with >> transparent=True, if you supply facecolor and/or edgecolor to the savefig >> call, those values should be used for the figure patch when the figure is >> saved. This might be useful if you want to keep the line around the figure, >> for example. >> > > This still does not work for me. I dug around a bit and found an > issue. Figure.savefig() sets the 'edgecolor' and 'facecolor' of the > axis patches but delegates the patches of the figure to the actual > print command. It does this by setting the edgecolor and facecolor > values in the kwargs dict. However, self.canvas.print_figure() > expects edgecolor and facecolor as args, not kwargs. So > print_figure() uses the default value: 'w' instead of 'none'. This is > a bit inconsistent, it seems, especially b/c the PS backend (which is > called after print_figure()) expects facecolor and edgecolor as > kwargs. I don't see this in the version as I changed it in svn r8282. Are you sure you installed and built from svn after I made the change? Using the attached script, I get the two attached (gzipped) eps files. The first with transparent=True, has no fill operations other than for generation of the glyphs; the second differs from the first in having two extra fill operations, one for the axes patch, the other for the figure patch. When I use your transeps.tex, run latex, and then dvips, the resulting ps file (also gzipped and attached) has the figure with a red background, sitting on a white page. I presume this is what you expect, and so the figure and axes really are transparent. Eric > > I went ahead and changed this, hoping it'd fix the issue, but it does > not. At least now, I can see that the edgecolor and facecolor are > both set to 'none' all the way until self.figure.draw(renderer) is > called. So somehow, the draw() command is unaffected by this still. > > What next? > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On Fri, Apr 30, 2010 at 1:55 AM, Eric Firing <ef...@ha...> wrote: > > I don't see this in the version as I changed it in svn r8282. Are you sure > you installed and built from svn after I made the change? Using the > attached script, I get the two attached (gzipped) eps files. The first with > transparent=True, has no fill operations other than for generation of the > glyphs; the second differs from the first in having two extra fill > operations, one for the axes patch, the other for the figure patch. > It looks like I messed up my install. On top of that, when I was testing this second time, I was not bothering to create the ps (from latex) and just using my OS's default EPS viewer to verify that transparency was working---the problem was that Evince displays images on a white background rather than on some distinguishing background to let me know that it is a transparent image. Sorry for the noise, its definitely working in r8282.