[tex-k] epstopdf bug?

[Pavel Sanda]

Hi,

attached is eps file which loads fine when using several postscript viewers
(e.g. gv, evince) but the content inside frame disappears when converting via
epstopdf.

The problem can be consistently reproduced by using matlab imagesc function
for graphs with scaled x axis. Not sure whether it's matlab producing
broken eps or epstopdf problem, but given that several viewers have no
problem to display the file I guess the later is the case.

Can anyone reproduce or give a hint how to fix this problem?

Thanks,
Pavel

[Akira Kakuto]

Hi,

Post by Pavel Sanda
Can anyone reproduce or give a hint how to fix this problem?

Try
epstopdf --pdfsettings=screen 2015-03-14.eps

[Karl Berry]

attached is eps file which loads fine when using several postscript
viewers (e.g. gv, evince) but the content inside frame disappears
when converting via epstopdf.

By the way, as far as I can see the underlying problem is related to the
gs version. epstopdf --debug shows the exact gs invocation, which is:

gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
-sOutputFile=2015-03-14.pdf -dPDFSETTINGS#/prepress -dMaxSubsetPct=100 \
-dSubsetFonts=true -dEmbedAllFonts=true -dAutoRotatePages#/None \
2015-03-14.eps -c quit

If I replace "gs" with "gs901", an older version I have on my system,
the interior of the frame appears. On the other hand, with gs910 as
well as gs914, it disappears as you reported.

You could report this to ghostscript at http://bugs.ghostscript.com/
if you feel like it, and see what they say. Akira's
--pdfsettings=screen workaround is fine, and there are probably other
workarounds by messing around with the options, but ultimately it still
seems to me there is a gs bug at the bottom of it.

Best,
Karl

[Pavel Sanda]

Post by Karl Berry
You could report this to ghostscript at http://bugs.ghostscript.com/
if you feel like it, and see what they say. Akira's

Thanks everyone involved, the issue has been fixed now, see bug
http://bugs.ghostscript.com/show_bug.cgi?id=696152

It was also suggested that:

"In any event, I'd very strongly recommend removing the PDFSETTINGS, if you (or
the epstopdf people) require specific PDF settings then they should be set
individually, not in a block." (Comment 4).

You might want to consider that for epstopdf codebase.

Thanks,
Pavel

[Reinhard Kotucha]

Post by Pavel Sanda

Post by Karl Berry
You could report this to ghostscript at http://bugs.ghostscript.com/
if you feel like it, and see what they say. Akira's

Thanks everyone involved, the issue has been fixed now, see bug
http://bugs.ghostscript.com/show_bug.cgi?id=696152
"In any event, I'd very strongly recommend removing the
PDFSETTINGS, if you (or the epstopdf people) require specific PDF
settings then they should be set individually, not in a block."
(Comment 4).

But Ken Sharpe also said:

| > Is this the final answer or is my report still considered as a bug
| > to be solved?
|
| As I said in comment #4: "I'm aware there's a problem, it exists in
| master also" so yes its a bug. It'll be addressed when I have time.

If this means that all the individual settings work properly but the
-dPDFSETTINGS option (which only bundles these settings) doesn't work,
it can't be too difficult to provide a fix. I really hope that Ken
has some time in the near future.

As far as epstopdf is concerned, there is nothing to do because all
the settings can be set individually already.

$epstopdf --help
[...]
Options for Ghostscript:
--gscmd=VAL pipe output to VAL (default: gs)
--gsopt=VAL single option for gs (see below)
--gsopts=VAL options for gs (see below)
[...]

Even if --pdfsettings is currently broken, I strongly recommend to
keep it.

As a maintainer of Ghostscript for Windows in TeX Live, I had to deal
with bugs in gs several times in the past. Sometimes I've been asked
to skip a particular release due to known bugs and it also happened
that I had to revert to an older release. But in all cases *known*
bugs had been fixed in the next release.

Pavel, I'm very grateful that you reported the bug and I'm very
confident that it will be fixed soon.

You said that Matlab's imagesec function currently doesn't work.
Removing -dPDFSETTINGS from epstopdf doesn't solve the problem.
The problem can only be circumvented if Matlab passes all the
individual PDF settings to epstopdf but I doubt that they are willing
to provide a workaround for a problem which most likely disappears
very soon.

Can you live with gs-9.01 for the time being and wait for a new
release of Ghostscript?

But by all means, epstopdf should *not* be changed.

Pavel, delivering a bug report to Ghostscript's bug tracker was by far
the best thing you could do. There is no other reasonable solution.

Regards,
Reinhard