Bug 912398 - Asymptote in Texlive uses ghostscript epswrite device which is not present
Asymptote in Texlive uses ghostscript epswrite device which is not present
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Other
13.2
All openSUSE 13.2
: P5 - None : Normal (vote)
: ---
Assigned To: Dr. Werner Fink
E-mail List
:
Depends on:
Blocks: 925371
  Show dependency treegraph
 
Reported: 2015-01-09 03:40 UTC by Don Raboud
Modified: 2015-04-20 11:00 UTC (History)
4 users (show)

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
LaTeX file + 2 EPS files (192.43 KB, application/octet-stream)
2015-01-28 11:28 UTC, Ulrich Deiters
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Don Raboud 2015-01-09 03:40:38 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
Comment 1 Don Raboud 2015-01-09 03:45:21 UTC
"epswrite" also appears in

utils/asymptote/runlabel.in
texk/texlive/linked_scripts/epspdf/epspdf.tlu

as well.
Comment 2 Dr. Werner Fink 2015-01-09 09:21:08 UTC
Interesting that no one had beeb informed about this change. Also I do not know if "eps2write" can be used as replacement for "epswrite"
Comment 3 Johannes Meixner 2015-01-09 10:56:25 UTC
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.
Comment 4 Ulrich Deiters 2015-01-28 11:28:12 UTC
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!
Comment 5 Dr. Werner Fink 2015-01-28 11:53:55 UTC
(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/
Comment 6 Johannes Meixner 2015-01-28 15:33:34 UTC
The upstream bug report is
http://bugs.ghostscript.com/show_bug.cgi?id=695503
Comment 7 Dr. Werner Fink 2015-01-28 15:39:33 UTC
(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?
Comment 8 Johannes Meixner 2015-01-28 15:45:46 UTC
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.
Comment 9 Johannes Meixner 2015-01-28 15:48:38 UTC
Regarding "re-enabling epswrite" see what Ken Sharp wrote in
http://bugs.ghostscript.com/show_bug.cgi?id=695503
Comment 10 Dr. Werner Fink 2015-01-28 15:54:03 UTC
(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.
Comment 11 Johannes Meixner 2015-01-29 09:18:39 UTC
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.
Comment 12 Dr. Werner Fink 2015-04-01 08:44:44 UTC
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.
Comment 13 Bernhard Wiedemann 2015-04-01 12:00:23 UTC
This is an autogenerated message for OBS integration:
This bug (912398) was mentioned in
https://build.opensuse.org/request/show/293919 Factory / texlive
Comment 14 Bernhard Wiedemann 2015-04-01 13:00:18 UTC
This is an autogenerated message for OBS integration:
This bug (912398) was mentioned in
https://build.opensuse.org/request/show/293948 Factory / texlive
Comment 15 Bernhard Wiedemann 2015-04-20 11:00:07 UTC
This is an autogenerated message for OBS integration:
This bug (912398) was mentioned in
https://build.opensuse.org/request/show/298147 Factory / texlive