Bug 695503

In the attached .tar file the "file.ps" was *NOT* created by Ghostscript. The
header is:
%!PS-Adobe-2.0
%%Creator: dvips(k) 5.993 Copyright 2013 Radical Eye Software

The files created by Ghostscript, fig_eps2write.eps:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 30 35 703 532
%%HiResBoundingBox: 30.786 35.808 702.276 531.540
%%Creator: GPL Ghostscript 914 (eps2write)
%%LanguageLevel: 2

and fig_epswrite.eps:

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 30 35 703 532
%%HiResBoundingBox: 30.400 35.800 702.300 531.540
%.....................................
%%Creator: GPL Ghostscript 914 (epswrite)
%%CreationDate: 2014/09/21 23:01:52
%%DocumentData: Clean7Bit
%%LanguageLevel: 2

open fine in Ghostscript. Most likely, the encapsulation of fig2_epswrite.eps
by dvips relies on assumptions that are not valid.

I extracted the fig_eps2write.eps that is embedded in file.ps (dumping to hex)
and the '04' characters in the original fig_eps2write.eps are missing from the
part that is embedded in file.ps. Also, the '0D' characters in the original
have been changed to '0A'.

I suggest that dvips is the problem, and suggest that eps2write file should
be created with:
   -dASCII85EncodePages=true
so that the result will not include binary data.

If this still fails, please open a bug with the dvips authors.

He never claimed that file.ps were created by gs, rather that the /LZWDecode /ASCII85Decode encoded output of eps2write does not work when the goal is to include the file in a ΤεΧ-generated file.

It would be useful were eps2write not to compress its output the way ps2write does.

I’m sure dvips is not the only eps consumer which will have problems with that.

Created attachment 11433 [details]
test case: LaTeX file + 2 EPS files

I created the EPS file hdr_KDK.eps by hand (as a letter background). When I run LaTeX, using this EPS file,

latex doc
dvips -t a4 -o doc.ps doc

I obtain a PS file in which some text parts are missing. Using the same in the EPS file and in the LaTeX document evidently created some collision. Previously, I could get around that by re-writing the EPS file with "epswrite" (this is the hdr_KDK2.eps file). When I now use "eps2write", the resulting PS file is broken. Okular shows a blank page, and gs gives the error message "%%[ Error handled by opdfread.ps : undefined; OffendingCommand: end92 ]%%" .

Using the "-dASCII85EncodePages=true" option helps – but then I have the missing-characters problem again.

(In reply to Ulrich Deiters from comment #3)
> Created attachment 11433 [details]
> test case: LaTeX file + 2 EPS files
> 
> I created the EPS file hdr_KDK.eps by hand (as a letter background). When I
> run LaTeX, using this EPS file,
> 
> latex doc
> dvips -t a4 -o doc.ps doc
> 
> I obtain a PS file in which some text parts are missing. Using the same in
> the EPS file and in the LaTeX document evidently created some collision.
> Previously, I could get around that by re-writing the EPS file with
> "epswrite" (this is the hdr_KDK2.eps file). When I now use "eps2write", the
> resulting PS file is broken. Okular shows a blank page, and gs gives the
> error message "%%[ Error handled by opdfread.ps : undefined;
> OffendingCommand: end92 ]%%" .
> 
> Using the "-dASCII85EncodePages=true" option helps – but then I have the
> missing-characters problem again.

I'm unsure why that is our problem, if the original EPS file doesn't work, I can't see why you should expect it to work after passing through eps2write.

It may be that the (horrible) low level code produced by epswrite fixed your EPS in some way (probably because it doesn't emit text in fonts, but uses bitmaps instead), but that's not a good reason to use it.

You should complain to the LaTex developers or fix your EPS file.

My original EPS file is OK. The problem is that some piece of software - dvips or gs – does not handle the encapsulation correctly. As the gs developers took epswrite away, it is only logical that I am complaining here. :-)

Perhaps I should turn to the dvips developers. But meanwhile it would be nice to have epswrite back as a temporary workaround.

(In reply to Ulrich Deiters from comment #5)

> dvips or gs – does not handle the encapsulation correctly. As the gs
> developers took epswrite away, it is only logical that I am complaining
> here. :-)

IMO not really, epswrite was never intended to fix problem PostScript. Its output was bloated and ugly, slow, and resolution dependent. The current code is better in many ways.

Of course it doesn't fix your particular problem, but then it wasn't intended to, it was intended to address the reasonable complaints about limited features, poor quality output etc.

 
> Perhaps I should turn to the dvips developers. But meanwhile it would be
> nice to have epswrite back as a temporary workaround.

You can add the device back yourself if you want it, to the best of my knowledge it still compiles. This is open-source software after all. You only need to edit the makefile.