|
From: Tom J. <tj...@gm...> - 2007-09-23 20:47:45
|
Hello,
When using usetex=True and
savefig(file, facecolor='w', edgecolor='w')
The behavior of the generated EPS file is more like:
facecolor=None
edgecolor='w'
That is, the image's facecolor is tranparent...taking on the background
color of the latex document---while the edgecolor is definitely white.
This seems inconsistent to me, and I was wondering if there was a quick
solution. I actually like that the facecolor is transparent (or
nonexistent)...and I would like the same to hold for the edgecolor. As of
now, I have an ugly white border around my image.
Also, it seems like there needs to be an extra keyword or option. Suppose
someone wanted a white facecolor in the (usetex=True) EPS file. It doesn't
seem like this is currently possible. It would be nice if I could specify:
savefig(file, facecolor=None, edgecolor=None)
Thoughts?
\documentclass{article}
\usepackage{pstricks}
\usepackage{graphicx}
\begin{document}
\psframe*[linecolor=blue](-10in,-10in)(10in,10in)
\includegraphics{test}
from matplotlib import rc, rcParams
rc('text', usetex=True)
rc('ps', usedistiller='xpdf')
from pylab import *
subplot(111,axisbg='red')
plot(range(10))
savefig('test.eps', facecolor='white', edgecolor='white')
|
|
From: Tom J. <tj...@gm...> - 2007-09-23 21:25:17
|
On 9/23/07, Tom Johnson <tj...@gm...> wrote: > > > Also, it seems like there needs to be an extra keyword or option. Suppose > someone wanted a white facecolor in the (usetex=True) EPS file. It doesn't > seem like this is currently possible. It would be nice if I could specify: > > savefig(file, facecolor=None, edgecolor=None) It would also be nice if we could specify the axis background color to be None as well (again, perhaps only useful when creating an EPS)...when using the plot command. |
|
From: Tom J. <tj...@gm...> - 2007-09-26 19:30:44
|
Any comments on this? The behavior is, at best, inconsistent. At worst, the current behavior is incorrect, as it is not possible to have a white facecolor when using usetex/xpdf. On 9/23/07, Tom Johnson <tj...@gm...> wrote: > > On 9/23/07, Tom Johnson <tj...@gm...> wrote: > > > > > > Also, it seems like there needs to be an extra keyword or option. > > Suppose someone wanted a white facecolor in the (usetex=True) EPS file. It > > doesn't seem like this is currently possible. It would be nice if I could > > specify: > > > > savefig(file, facecolor=None, edgecolor=None) > > > It would also be nice if we could specify the axis background color to be > None as well (again, perhaps only useful when creating an EPS)...when using > the plot command. > > > |
|
From: Darren D. <dd...@co...> - 2007-09-26 20:40:20
Attachments:
dsd_test.ps
|
On Wednesday 26 September 2007 03:30:41 pm Tom Johnson wrote:
> Any comments on this? The behavior is, at best, inconsistent. At worst,
> the current behavior is incorrect, as it is not possible to have a white
> facecolor when using usetex/xpdf.
I used your script to create the eps file, and created the attached postscript
(you need an \end{document} in your latex code). Do you see anything wrong
with the resulting postscript? It looks fine to me.
> On 9/23/07, Tom Johnson <tj...@gm...> wrote:
> > On 9/23/07, Tom Johnson <tj...@gm...> wrote:
> > > Also, it seems like there needs to be an extra keyword or option.
> > > Suppose someone wanted a white facecolor in the (usetex=True) EPS file.
> > > It doesn't seem like this is currently possible. It would be nice if
> > > I could specify:
> > >
> > > savefig(file, facecolor=None, edgecolor=None)
> >
> > It would also be nice if we could specify the axis background color to be
> > None as well (again, perhaps only useful when creating an EPS)...when
> > using the plot command.
That is probably a nontrivial change to mpl's existing color support.
Darren
|
|
From: Darren D. <dd...@co...> - 2007-09-27 13:34:32
Attachments:
mpl.pdf
|
On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:
> On 9/26/07, Darren Dale <dd...@co...> wrote:
> > I used your script to create the eps file, and created the attached
> > postscript
> > (you need an \end{document} in your latex code).
>
> Whoops!
>
>
> Do you see anything wrong
>
> > with the resulting postscript? It looks fine to me.
>
> Indeed. I didn't realize this before, but the problem is actually with the
> pdf. I have attached it. Can you confirm that your pdf looks like mine?
No, it does not look like yours. See attached.
> Mine looks like this no matter which viewer I use (acrobat, evince, xpdf).
> This makes me wonder if it is 1) the eps file or 2) the compilation
> process.
It is probably a problem with either ghostscript or pdftops.
> Actually, the problem exists as early as the dvi file.
The dvi looks fine here, and so does my pdf. It is often the case that
problems with usetex are solved by updating the external dependencies. I am
using:
GPL Ghostscript 8.60
pdftops version 3.00
pdfeTeX 3.141592-1.30.5-2.2 (tetex-3.0_p1)
|
|
From: Darren D. <dd...@co...> - 2007-09-27 13:52:28
|
On Thursday 27 September 2007 09:34:28 am Darren Dale wrote:
> On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:
> > On 9/26/07, Darren Dale <dd...@co...> wrote:
> > > I used your script to create the eps file, and created the attached
> > > postscript
> > > (you need an \end{document} in your latex code).
> >
> > Whoops!
> >
> >
> > Do you see anything wrong
> >
> > > with the resulting postscript? It looks fine to me.
> >
> > Indeed. I didn't realize this before, but the problem is actually with
> > the pdf. I have attached it. Can you confirm that your pdf looks like
> > mine?
>
> No, it does not look like yours. See attached.
>
> > Mine looks like this no matter which viewer I use (acrobat, evince,
> > xpdf). This makes me wonder if it is 1) the eps file or 2) the
> > compilation process.
>
> It is probably a problem with either ghostscript or pdftops.
>
> > Actually, the problem exists as early as the dvi file.
>
> The dvi looks fine here, and so does my pdf. It is often the case that
> problems with usetex are solved by updating the external dependencies. I am
> using:
>
> GPL Ghostscript 8.60
> pdftops version 3.00
> pdfeTeX 3.141592-1.30.5-2.2 (tetex-3.0_p1)
On my machine, pdftops is provided by poppler-0.6, not xpdf.
Darren
|
|
From: Tom J. <tj...@gm...> - 2007-09-27 18:22:20
|
On 9/27/07, Darren Dale <dd...@co...> wrote:
> On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:
> > On 9/26/07, Darren Dale <dd...@co...> wrote:
> > > I used your script to create the eps file, and created the attached
> > > postscript
> > > (you need an \end{document} in your latex code).
> >
> > Whoops!
> >
> >
> > Do you see anything wrong
> >
> > > with the resulting postscript? It looks fine to me.
> >
> > Indeed. I didn't realize this before, but the problem is actually with the
> > pdf. I have attached it. Can you confirm that your pdf looks like mine?
>
> No, it does not look like yours. See attached.
Interesting.
>
> > Mine looks like this no matter which viewer I use (acrobat, evince, xpdf).
> > This makes me wonder if it is 1) the eps file or 2) the compilation
> > process.
>
> It is probably a problem with either ghostscript or pdftops.
>
> > Actually, the problem exists as early as the dvi file.
>
> The dvi looks fine here, and so does my pdf. It is often the case that
> problems with usetex are solved by updating the external dependencies. I am
> using:
>
> GPL Ghostscript 8.60
> pdftops version 3.00
> pdfeTeX 3.141592-1.30.5-2.2 (tetex-3.0_p1)
>
>
>
Hmm...I have:
ESP Ghostscript 8.15.04 (2007-03-14)
pdftops version 3.01 (coming from libpoppler1 version 0.5.4-0ubuntu8)
pdfeTeX 3.141592-1.21a-2.2 (tetex-3.0.dfsg.3-4)
The CUPS page (http://www.cups.org/espgs/index.php) indicates that ESP
8.15.04 and GPL 8.57 have merged into 8.60. This is probably the
solution. So I will give that a try as a first fix and report back to
the list.
However, it will be a little while before I can provide a status
update----I have a presentation very soon and do not have the time to
regenerate all my images so that the background matches my
presentation background. Since my setup had been creating
'transparent' facecolors, I did not bother setting facecolor at all
and kept the default. :(
Thanks!
|
|
From: Tom J. <tj...@gm...> - 2007-09-27 18:30:20
|
On 9/27/07, Tom Johnson <tj...@gm...> wrote: > However, it will be a little while before I can provide a status > update----I have a presentation very soon and do not have the time to > regenerate all my images so that the background matches my > presentation background. Since my setup had been creating > 'transparent' facecolors, I did not bother setting facecolor at all > and kept the default. :( Assuming that GPL 8.60 fixes the problem, do you anticipate that mpl will move to support None as a color? I realize this is a nontrivial change to the color functionality...but there is a major portability benefit. With None as an option, I would probably always set the axis background color, figure facecolor, and figure edgecolor to None. Then, my figures would work no matter which theme I selected for my presentation....and it avoids the situation I am in now, which requires significant time to regenerate images. > > Thanks! > |
|
From: Tom J. <tj...@gm...> - 2007-10-01 17:25:25
|
On 9/27/07, Tom Johnson <tj...@gm...> wrote: > On 9/27/07, Darren Dale <dd...@co...> wrote: > > On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote: [snip] > > > Actually, the problem exists as early as the dvi file. > > > > > The dvi looks fine here, and so does my pdf. [snip] > Hmm...I have: > > ESP Ghostscript 8.15.04 (2007-03-14) > pdftops version 3.01 (coming from libpoppler1 version 0.5.4-0ubuntu8) > pdfeTeX 3.141592-1.21a-2.2 (tetex-3.0.dfsg.3-4) > After doing some upgrades, I think I have more information about this issue. In summary, the problem is fixed, but I think there are still some questions as to the cause of the earlier problem. Currently, I have: GPL Ghostscript 8.61 pdftops version 3.02 pdfTeX 3.141592-1.40.3-2.2 If I use the scripts in the original email, then there is no problem. That is, with facecolor='white', the resulting eps, dvi, ps, and pdf all have a figure with a white facecolor. Strangely, if I use an EPS from before my upgrades, the problem still exists. This has the fortunate effect that I do not need to regenerate all my images. In this situation, as described previously, the eps file looks fine using gv (has a white facecolor). However, the resulting dvi, ps, and pdf all have a figure with no facecolor---and this behavior not consistent with edgecolor. I am using the same version of matplotlib (before and after the upgrade)... SVN Revision 3709...and python 2.5 as well. Since the problem still occurs with particular EPS files....the problem definitely must be with the EPS. I don't know how the EPS file is constructed in matplotlib...does it make use of external programs like gs (and thus, points the reason back at EPS Ghostscript)? In case someone is interested in searching for the source of the problem, I have attached: 1) good.eps (which has a white facecolor when included in a document) 2) bad eps (which has no facecolor when included in a document) 3) test.pdf (a demonstration of both images in one document) 4) test.tex (the source for test.pdf) Thanks! |
|
From: Darren D. <dd...@co...> - 2007-10-01 20:23:08
|
On Monday 01 October 2007 01:25:11 pm Tom Johnson wrote: > On 9/27/07, Tom Johnson <tj...@gm...> wrote: > > On 9/27/07, Darren Dale <dd...@co...> wrote: > > > On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote: > > [snip] > > > > > Actually, the problem exists as early as the dvi file. > > > > > > The dvi looks fine here, and so does my pdf. > > [snip] > > > Hmm...I have: > > > > ESP Ghostscript 8.15.04 (2007-03-14) > > pdftops version 3.01 (coming from libpoppler1 version 0.5.4-0ubuntu8) > > pdfeTeX 3.141592-1.21a-2.2 (tetex-3.0.dfsg.3-4) > > After doing some upgrades, I think I have more information about this > issue. In summary, the problem is fixed, but I think there are still > some questions as to the cause of the earlier problem. Currently, I > have: > > GPL Ghostscript 8.61 > pdftops version 3.02 > pdfTeX 3.141592-1.40.3-2.2 > > If I use the scripts in the original email, then there is no problem. > That is, with facecolor='white', the resulting eps, dvi, ps, and pdf > all have a figure with a white facecolor. > > Strangely, if I use an EPS from before my upgrades, the problem still > exists. This has the fortunate effect that I do not need to > regenerate all my images. In this situation, as described previously, > the eps file looks fine using gv (has a white facecolor). However, > the resulting dvi, ps, and pdf all have a figure with no > facecolor---and this behavior not consistent with edgecolor. > > I am using the same version of matplotlib (before and after the > upgrade)... SVN Revision 3709...and python 2.5 as well. Since the > problem still occurs with particular EPS files....the problem > definitely must be with the EPS. > > I don't know how the EPS file is constructed in matplotlib...does it > make use of external programs like gs (and thus, points the reason > back at EPS Ghostscript)? In case someone is interested in searching > for the source of the problem, I have attached: It was a problem introduced by one of the external dependencies during the distillation process, that's why your old eps files still look the way they do. It was not a problem with the viewer. It looks like the problem was fixed in a recent ghostscript release, and I don't think the matplotlib mailing lists are an appropriate forum for discussing problems with ghostscript. Darren |