Bugzilla – Bug 912398
Asymptote in Texlive uses ghostscript epswrite device which is not present
Last modified: 2015-04-20 11:00:07 UTC
asymptote tries to use ghostscript device "epswrite" but that device is no longer supported by ghostscript and appears to have been replaced by the "eps2write" device instead. "epswrite" appears in the file utils/asymptote/runlabel.cc in the texlive source rpm while gs --help does not list epswrite as a supported device, but eps2write is shown as one of the supported devices. Generating asymptote files containing 3D labels doesn't work, although the same asymptote file works fine in 12.3 and I suspect this may be the cause. texlive-2013.20130620-23.1.9.src.rpm ghostscript-9.15-1.4.x86_64
"epswrite" also appears in utils/asymptote/runlabel.in texk/texlive/linked_scripts/epspdf/epspdf.tlu as well.
Interesting that no one had beeb informed about this change. Also I do not know if "eps2write" can be used as replacement for "epswrite"
When there is no RPM dependency that package 'foo' needs 'something' from package 'bar' then 'something' can get silently dropped from package 'bar'. For a maintainer of package 'bar' it is totally impossible to find out with reasonable effort what of package 'bar' is silently needed by other packages. Ghostscript upstream changes Ghostscript as they need it. The changes are usually listed in the Ghostscript upstream "History". For epswrite versus eps2write in the current Ghostscript see /usr/share/ghostscript/9.15/doc/History9.htm excerpt: -------------------------------------------------------------------------- Version9.15 ... Remove epswrite (the final "subdevice" of pswrite) and references to it. ... Version9.14 ... A new device 'eps2write' has been added which allows for the creation of EPS files using the ps2write device instead of the old (deprecated and removed) pswrite device. This produces considerably better quality EPS files than the old epswrite device which is now also deprecated and will be removed in a future release. -------------------------------------------------------------------------- This change is also mentioned in our 'ghostscript' RPM changelog: -------------------------------------------------------------------------- * Thu Mar 27 2014 jsmeix@suse.de ... * A new device 'eps2write' has been added which allows for the creation of EPS files using the ps2write device instead of the deprecated and removed pswrite device. The epswrite device is now also deprecated and will be removed in a future release. -------------------------------------------------------------------------- As maintainer of package 'ghostscript' I try to catch all incompatible changes in the Ghostscript upstream "History" and mention them in our 'ghostscript' RPM changelog but there is no guarantee that I really get all incompatible changes in any case.
Created attachment 621196 [details] LaTeX file + 2 EPS files Eps2write is positively not a good replacement for epswrite! The attached zip archive contains 2 EPS files. hdr_KDK.eps is the original letter background. I created hdr_KDK2.eps with gs -sDEVICE=eps2write -sOutputFile=hdr_KDK2.eps hdr_KDK.eps hdr_KDK2.eps seems OK when one looks at it with okular, gv, etc. But when the LaTeX document is compiled, latex doc dvips -t a4 -o doc.ps doc the resulting PS file is damaged: Okular shows a blank page, and gs gives the error message "%%[ Error handled by opdfread.ps : undefined; OffendingCommand: end92 ]%%" PLease give us epswrite back!
(In reply to Ulrich Deiters from comment #4) I'm not able to so. Please report it upstream at ghostscript http://ghostscript.com/cgi-bin/mailman/listinfo/gs-bugs http://bugs.ghostscript.com/
The upstream bug report is http://bugs.ghostscript.com/show_bug.cgi?id=695503
(In reply to Johannes Meixner from comment #6) From http://bugs.ghostscript.com/show_bug.cgi?id=695503#c6 > > 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. ... should I file a bug against ghostscript for re-enabling epswrite?
In http://bugs.ghostscript.com/show_bug.cgi?id=695503#c3 Ulrich Deiters writes about "missing characters" which reminds me of bug#897284 and in http://bugs.ghostscript.com/show_bug.cgi?id=695503#c4 Ken Sharp writes ---------------------------------------------------------------- the (horrible) low level code produced by epswrite ... it doesn't emit text in fonts, but uses bitmaps instead) ---------------------------------------------------------------- From my non-expert point of view this matches bug#897284 and what is described there.
Regarding "re-enabling epswrite" see what Ken Sharp wrote in http://bugs.ghostscript.com/show_bug.cgi?id=695503
(In reply to Johannes Meixner from comment #9) I've read it ... and do not see what you mean. Is it possible to re-enable epswrite (it seems yes), should we do it (IMHO yes). If you do not want to do this I can not do anything as I will not hack dvips.
Sorry, my comment#9 is not clear because in http://bugs.ghostscript.com/show_bug.cgi?id=695503 Ken Sharp also wrote that it should be easy for someone who wants 'epswrite' to make his own Ghostscript with it. Clarification: As long as I have to maintain Ghostscript at SUSE it will be in full compliance with upstream, cf. https://bugzilla.opensuse.org/show_bug.cgi?id=735824#c36 (you may also have a look at bug#913694). This means Ghostscript from openSUSE will not have non-upstream-compliant stuff. In particular it will not have devices that are intentionally disabled by Ghostscript upstream. On the other hand this also means: Who wants something different must either work together directly with Ghostscript upstream or he must make and maintain his own Ghostscript. With the openSUSE build service it is easy for a somewhat experienced Linux user to build his own Ghostscript. If someone wants non-upstream-compliant stuff for Ghostscript at SUSE, he must maintain Ghostscript at SUSE. Regarding the initial issue here (comment#0): According to what Ken Sharp also wrote in http://bugs.ghostscript.com/show_bug.cgi?id=695503 -------------------------------------------------------------------------- epswrite ... output was bloated and ugly, slow, and resolution dependent. The current code is better in many ways. -------------------------------------------------------------------------- and according to what I quoted in comment#3 -------------------------------------------------------------------------- 'eps2write' ... produces considerably better quality EPS files -------------------------------------------------------------------------- the change from epswrite to eps2write should be an improvement. Regarding the different issue from Ulrich Deiters: In Ulrich Deiters' particular case Ken Sharp wrote in http://bugs.ghostscript.com/show_bug.cgi?id=695503 --------------------------------------------------------------------------- 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) --------------------------------------------------------------------------- and it seems eps2write better quality output does no longer fix Ulrich Deiters' EPS (probably because eps2write emits text in fonts) so that for Ulrich Deiters' particular case eps2write can be no longer used as workaround to fix his particular issue as I described in https://bugzilla.opensuse.org/show_bug.cgi?id=897284#c21 I think Ulrich Deiters' real issue is described in bug#897284 Ulrich Deiters, I am really not an expert in this area but as far as I understand it you need a Ghostscript device that outputs EPS where text is not drawn by using fonts (because later dvips may mess up font stuff) but where text is drawn by emitting the glyph description directly into the page stream every time a glyph is used. Ulrich Deiters, instead of submitting a bug report to upstream Ghostscript (as far as I see there is no bug here in Ghostscript), you may ask on the the gs-devel@ghostscript.com mailing list and describe you issue together with references to http://bugs.ghostscript.com/show_bug.cgi?id=695508 and http://bugs.ghostscript.com/show_bug.cgi?id=695503 Perhaps the Ghostscript authors agree that it would be useful to have an option (of course not by default) so that text is not drawn by using fonts but where text is drawn by emitting the glyph description directly into the page stream every time a glyph is used.
I've added a patch to make asymptote to use eps2write. I'm aware that this does not fix the problem that the resulting eps files are not usable with other postscript code. This is a bug in eps2write device of ghostscript AFAICS from the reports listed by google: https://stackoverflow.com/questions/28917496/is-it-possible-to-use-eps-file-created-with-eps2write-in-endpage-procedure https://www.tug.org/pipermail/tex-live/2015-February/036275.html it looks like the results of the device eps2write are not able to survice EndPage procedure even with the same ghostscript.
This is an autogenerated message for OBS integration: This bug (912398) was mentioned in https://build.opensuse.org/request/show/293919 Factory / texlive
This is an autogenerated message for OBS integration: This bug (912398) was mentioned in https://build.opensuse.org/request/show/293948 Factory / texlive
This is an autogenerated message for OBS integration: This bug (912398) was mentioned in https://build.opensuse.org/request/show/298147 Factory / texlive