Hide Forgot
This has already been fixed in https://bugzilla.redhat.com/show_bug.cgi?id=657290 Description of problem: When you include an EPS file in an xfig figure, ghostscript gets called but produces an error, and no figure is included. The same is true if you open a .fig file that has an EPS embedded. Version-Release number of selected component (if applicable): xfig-3.2.5-23.b.el6.x86_64 How reproducible: Steps to Reproduce: 1. Start xfig 2. click on the picture icon 3. browse to an EPS file Actual results: ERROR from ghostscript: Error: /invalidfileaccess in --run-- Operand stack: 3 --nostringval-- (p1814a.ps) (r) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- . . . . GPL Ghostscript 8.71: Unrecoverable error, exit code 1 EPS object read OK, but no preview bitmap found/generated Xfig continures, but the EPS is not showing up. Expected results: Figure displaying with the EPS file in it.
No such build has ever existed and I cannot reproduce with latest version in 6.2 (which is xfig-3.2.5-22.a.1.el6). Closing, but if you can reproduce with latest official build feel free to reopen.
Created attachment 575229 [details] .fig file which will reproduce the problem. This figure contains an encapsulated postscript file. When opened it will cause xfig to crash.
Reopening bug, as I can confirm issue exists with latest package version. I am uploading the patch that fixes the issue.
Created attachment 575230 [details] Patch to rectify issue reading eps files Uploaded xfig-3.2.5b-fix-eps-reading.patch which I have tested and can confirm as fixing the issue.
Attached file contains just the fig file, but the eps is actually not there just linked from it. That's how xfig handles eps files inside figures. Even if I provide some eps file, xfig is still able to open it without problems and I cannot reproduce. Can you perhaps make a tarball with: * reproducer.fig * circle.eps Also: > This figure contains an encapsulated postscript file. When opened it will cause > xfig to crash. Original report was about ghostscript producing an error which would suggest the problem is actually the eps file and/or ghostscript. Plus there was no mention of xfig crashing. That would be a different bug probably. Please include at least circle.eps, otherwise I can't reproduce
Created attachment 575610 [details] eps file which causes error message I have attached circle.eps. Apologies for previous mis-inclusion before. This file when trying to add as a picture to an xfig document causes an error message to be displayed. The application does not crash, but is unable to show the embedded file.
As weird as this sounds I still cannot reproduce. Can you walk me through it? I would like to exactly replicate your steps. I am especially interested in: * placement of files on filesystem * current directory when you run xfig Also, just to be sure, output of: $ rpm -q ghostscript xfig
Created attachment 575868 [details] Screenshot of issue occurring Steps for reproducing: 1. Open xfig 2. Select Picture (the camera button) 3. draw the selection area 4. select browse 5. choose circle.eps # rpm -q ghostscript xfig ghostscript-8.70-11.el6_2.6.x86_64 xfig-3.2.5-22.a.1.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause Security errata RHSA-2012:0095 changed the way ghostscript handles relative paths. Consequence Xfig relies on old ghostscript behaviour and because of this fails to open encapsulated postscript files and instead shows an error. Fix Xfig was changed to use absolute paths when executing ghostscript binary Result Xfig is able to open encapsulated postscript files and include them in other figures.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0985.html