Created attachment 11175 [details] Latex document and .eps files I have discovered a bug when using .eps files in latex that are generated with the eps2write device (which does not occur when I use epswrite). After creating a .dvi file from the latex document, I use 'dvips' to create a .ps file from the document. However, the pages containing the .eps images cannot be viewed (e.g. in zathura). Furthermore, I get the following error when I try to convert the resulting .ps document into a .pdf: > gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=file.pdf -f file.ps GPL Ghostscript 9.14 (2014-03-26) Copyright (C) 2014 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading StandardSymL font from %rom%Resource/Font/StandardSymL... 4258988 2575089 8322364 5247388 3 done. Loading NimbusRomNo9L-Regu font from %rom%Resource/Font/NimbusRomNo9L-Regu... 4454316 2972939 8322364 5273808 3 done. %%[ Error handled by opdfread.ps : ioerror; OffendingCommand: --nostringval-- ]%% Loading NimbusMonL-Regu font from %rom%Resource/Font/NimbusMonL-Regu... 4928964 3372277 8338996 5648633 4 done. %%[STACK: -mark- -mark- -mark- %%]% So you can see for yourself, I am attaching a .tar file containing the latex file along with two images: fig_epswrite.eps, and fig_eps2write.eps. They are both the same image, except generated by epswrite vs. eps2write. The latex file attempts to display both images. As you can easily verify, if the lines for displaying fig.eps2write.eps are commented out, the error disappears. The file.dvi and file.ps files are also included. Any help or patches would be greatly appreciated! Thanks, Quinn
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.