edgecolor with usetex=True, usedistiller='pdf'

Community matplotlib-users
1

> 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)

mpl.pdf (4.28 KB)

···

On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:

On 9/26/07, Darren Dale <dd55@...163...> wrote:

2

On my machine, pdftops is provided by poppler-0.6, not xpdf.

Darren

···

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 <dd55@...163...> 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)

3

> > 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. :frowning:

Thanks!

···

On 9/27/07, Darren Dale <dd55@...163...> wrote:

On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:
> On 9/26/07, Darren Dale <dd55@...163...> wrote:

4

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. :frowning:

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.

···

On 9/27/07, Tom Johnson <tjhnson@...287...> wrote:

Thanks!

5

[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!

bad.eps (32.4 KB)

good.eps (21.3 KB)

test.pdf (9.04 KB)

test.tex (253 Bytes)

···

On 9/27/07, Tom Johnson <tjhnson@...287...> wrote:

On 9/27/07, Darren Dale <dd55@...163...> wrote:
> On Thursday 27 September 2007 01:28:46 am Tom Johnson wrote:

6

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

···

On Monday 01 October 2007 01:25:11 pm Tom Johnson wrote:

On 9/27/07, Tom Johnson <tjhnson@...287...> wrote:
> On 9/27/07, Darren Dale <dd55@...163...> 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: