Bug 55772 - Problem rendering eps files in lyx-1.1.6fix3-1
Problem rendering eps files in lyx-1.1.6fix3-1
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: ghostscript (Show other bugs)
7.2
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Tim Waugh
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-06 08:52 EST by Emmanuel Druon
Modified: 2014-01-21 17:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 12:35:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
An EPS that causes ghostscript to never stop (11.02 KB, application/postscript)
2002-03-29 01:17 EST, Paul Dickson
no flags Details

  None (edit)
Description Emmanuel Druon 2001-11-06 08:52:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2-edr i686)

Description of problem:
Since installing RH 7.2, the rendering of eps files inside the lyx
application doesn't work anymore. I've the gs process running (as shown by
ps) but no output is produced.
I upgraded to ghostscript-6.51-16 but it's still not working.
I'm using  xforms-0.88-3 and lyx-1.1.6fix3-1
Note: everything worked fine with RH 7.1

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. include an EPS graphic in Lyx.
2. you see the message rendering... but nothing happens
3. ps indicates that a gs process is running but there doesn't seem to be
any result
	

Actual Results:  See above description

Expected Results:  A view of the EPS file inside the Lyx application

Additional info:
Comment 1 John Levon 2001-11-27 19:25:22 EST
(I'm the LyX developer who reported the original ghostscript bug.)

See
https://sourceforge.net/tracker/index.php?func=detail&aid=224957&group_id=1897&atid=101897
for the problem.

This bug is still present all the way up to 6.52 it seems.

It would be great if RedHat could apply the patch in that bug report
to their packaged gnu ghostscript -afaics there still isn't a gnu ghostscript
available with that bug fixed.
Comment 2 Andrew Gormanly 2001-12-04 10:52:01 EST
It would be really great if this could be fixed in Red Hat's GNU Ghostscript
RPM, as when I tried putting AFPL Ghostscript 7.03 in /usr/local on one of our
boxes, opening one guy's thesis caused X to crash out!

Should that be submitted as an XFree86 bug too?
Comment 3 Tim Waugh 2002-01-10 11:55:59 EST
Thanks for the patch.
Comment 4 Tim Waugh 2002-02-22 07:48:12 EST
Fix is applied in 6.53-1.
Comment 5 Paul Dickson 2002-03-29 01:17:32 EST
Created attachment 51304 [details]
An EPS that causes ghostscript to never stop
Comment 6 Paul Dickson 2002-03-29 01:29:02 EST
I have attached an EPS that, when run with gv, will cause ghostscript to not
stop running.  I have tested this with the RPMs 6.51-16 and the one in skipjack,
6.53-4.  All have the same result.

Also have this problem is ps2pdf and pstoedit.  In pstoedit, if I try to convert
the EPS to a SK (for Sketch), ghostscript never finishes.  But if I have pstodit
convert it to AI (for Adobe Illustrator), it works correctly.  Likewise if I
include this file in TeX document, ps2pdf has no problems.
Comment 7 Tim Waugh 2002-04-04 08:25:58 EST
Thanks for the attachment.
Comment 8 Tim Waugh 2002-04-04 08:44:56 EST
The offending fragment is this:

/null {clear} def

Not sure what it's supposed to do.  I don't know PostScript well enough to know
whether it ought to terminate or not.  I've reported this upstream.
Comment 9 Tim Waugh 2002-05-22 06:58:32 EDT
7.05-3 (from rawhide) does the same thing.
Comment 10 Alex Cherepanov 2002-10-15 11:49:38 EDT
By some reason Ghostscript doesn't bind null, true, and false all over
the code. lpd once said that //null looks ugly. So any attempt to redefine
these names screw up the code. I plan to bind all these names bur GS
development team considers this a low priority problem.
Comment 11 Tim Waugh 2002-10-15 12:21:50 EDT
(This is already reported upstream, via sourceforge)
Comment 12 Alex Cherepanov 2005-03-06 19:09:21 EST
Artifex made this a bounty bug. I submitted a patch on 2004-11-27
but it has not been reviewed. Please kick them and help me get
my bounty. For details see:
http://bugs.ghostscript.com/show_bug.cgi?id=687608
Comment 13 Bill Nottingham 2006-08-07 15:11:00 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 14 Bill Nottingham 2006-10-18 12:35:13 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.