Bug 55772

Summary: Problem rendering eps files in lyx-1.1.6fix3-1
Product: [Retired] Red Hat Linux Reporter: Emmanuel Druon <emmanuel.druon>
Component: ghostscriptAssignee: Tim Waugh <twaugh>
Status: CLOSED CANTFIX QA Contact: Aaron Brown <abrown>
Severity: low Docs Contact:
Priority: medium    
Version: 7.2CC: alexcher, paul, rh-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-18 16:35:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
An EPS that causes ghostscript to never stop none

Description Emmanuel Druon 2001-11-06 13:52:43 UTC
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-28 00:25:22 UTC
(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 15:52:01 UTC
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 16:55:59 UTC
Thanks for the patch.


Comment 4 Tim Waugh 2002-02-22 12:48:12 UTC
Fix is applied in 6.53-1.

Comment 5 Paul Dickson 2002-03-29 06:17:32 UTC
Created attachment 51304 [details]
An EPS that causes ghostscript to never stop

Comment 6 Paul Dickson 2002-03-29 06:29:02 UTC
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 13:25:58 UTC
Thanks for the attachment.

Comment 8 Tim Waugh 2002-04-04 13:44:56 UTC
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 10:58:32 UTC
7.05-3 (from rawhide) does the same thing.

Comment 10 Alex Cherepanov 2002-10-15 15:49:38 UTC
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 16:21:50 UTC
(This is already reported upstream, via sourceforge)

Comment 12 Alex Cherepanov 2005-03-07 00:09:21 UTC
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 19:11:00 UTC
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 16:35:13 UTC
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.