Created attachment 1721019 [details] File generated by gEDA PCB (a pcb designed by me). Description of problem: Until I upgrade Ghostscript, I loaded, no issues, my .ps files (exported from gEDA PCB). After upgrading, it renders no contents (pretty blank pages). When I revert version (9.52...) file is shown, no problem. Version-Release number of selected component (if applicable): ghostscript-9.53.1-2 How reproducible: Allways I try to open a .ps file via Okular or another frontend. Steps to Reproduce: 1. Open the .PS file: $ =>okular /home/morvan/eletr/caixa/meter.uln2004.poli.ps Actual results: **** Unable to open the initial device, quitting. (libspectre) ghostscript reports: fatal internal error -100org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [686x887] QImage::scaled: Image is a null image **** Unable to open the initial device, quitting. (libspectre) ghostscript reports: fatal internal error -100org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [686x887] QImage::scaled: Image is a null image... Expected results: view file contents Additional info: I tried some times, to be ascertain what bugged component.
The attached file works fine with ghostscript-9.53.3-1.fc31.x86_64 over here (copr build) but shows the same symptoms when ghostscript is called through zathura or evince. Can you confirm that calling ghostscript directly works for you with that file? Something around the parameters or the behaviour of -dSAFER may have changed.
OK, so apparantly, gs 9.53 needs an update to libspectre which is the library that evince and zathura-ps (and probably okular) use to interface with ghostscript. I built and installed libspectre-0.2.9-2.fc31.x86_64 on F31 which was everything I needed to get the ps file from the bug report to display with evince and zathura-ps. (It gave the same error as reported with libspectre-0.2.8-9.fc31.x86_64.) Note that none of these are available on F31 where I am testing. But gs 9.53 is on F32, and after my testing I am confident that a libspectre update to 0.2.9 on F32 (which is the version on F33 and F34) will solve the problem. This means we might have to coordinate gs and libspectre updates at least sometimes. Reassigning to libspectre: Please push your F33/F34 update to F32 as well.
For me, only approach that works is to downgrade Ghostscript, a sign that it is the culprit: # =>dnf install ghostscript-core ghostscript-tools-printing ghostscript-tools-fonts libspectre ... ghostscript x86_64 9.53.1-2.fc32 updates 38 k ghostscript-core x86_64 9.53.1-2.fc32 updates 8.7 k ghostscript-tools-fonts x86_64 9.53.1-2.fc32 updates 12 k ghostscript-tools-printing x86_64 9.53.1-2.fc32 updates 12 k ... Resume... Nothing. But, when I type: # =>dnf downgrade ghostscript-core ghostscript-tools-printing ghostscript-tools-fonts libspectre ... ghostscript x86_64 9.52-1.fc32 fedora 39 k ghostscript-core x86_64 9.52-1.fc32 fedora 9.3 k ghostscript-tools-fonts x86_64 9.52-1.fc32 fedora 13 k ghostscript-tools-printing x86_64 9.52-1.fc32 fedora 13 k libgs x86_64 9.52-1.fc32 fedora 3.1 M Everything shows up.
I'm not sure what "Resume... Nothing." and "Everything shows up." mean, but the point is the fact that libspectre on F32 needs to have the same update that you pushed to F33 already. That is what I am asking because the older libspectre cannot handle the newer libgs. dnf would tell you nothing about that. Trying out the attached ps with a ps viewer which uses libspectre is the check for that. libgs does not require libspectre and thus cannot "require" a specific version in spec. This can be handled only on the side of libspectre, the lib calling into gs.
Hi, the issue seems to be caused by a change in ghostscript between 9.52 and 9.53 (there were several changes in sizes of some types). Simple rebuild of libspectre fixes the issue. So I've prepared the rebuild. I've set version dependency on ghostscript 9.53 since the new build does not work with ghostscript 9.52. Thanks you for this report.
FEDORA-2020-6ca8e9b5c0 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ca8e9b5c0
FEDORA-2020-6ca8e9b5c0 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6ca8e9b5c0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ca8e9b5c0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Michael J Gruber from comment #4) > I'm not sure what "Resume... Nothing." and "Everything shows up." mean, but Hi. I, intentionally, omitted dnf verbosity. I mean I downgraded packages to test versions.
(In reply to Marek Kašík from comment #5) > Hi, > > the issue seems to be caused by a change in ghostscript between 9.52 and > 9.53 (there were several changes in sizes of some types). Simple rebuild of > libspectre fixes the issue. So I've prepared the rebuild. I've set version > dependency on ghostscript 9.53 since the new build does not work with > ghostscript 9.52. > > Thanks you for this report. Thats is right. You are welcome. Thanks for kind response.
(In reply to Fedora Update System from comment #7) > FEDORA-2020-6ca8e9b5c0 has been pushed to the Fedora 32 testing repository. ... Thanks.
(In reply to Marek Kašík from comment #5) > Hi, > > the issue seems to be caused by a change in ghostscript between 9.52 and > 9.53 (there were several changes in sizes of some types). Simple rebuild of > libspectre fixes the issue. So I've prepared the rebuild. I've set version > dependency on ghostscript 9.53 since the new build does not work with > ghostscript 9.52. > > Thanks you for this report. The problem is also present in Fedora 33 and the same solution applies there. Just rebuilding libspectre is enough to make okular and evince work again with postscript files. Another symptom from this problem was that without the rebuild "Print Preview" is not working in okular for pdf files. Should I open another bug for Fedora 33? In this case the cause and the solution are the same. :-)
FEDORA-2020-aab53a1bbb has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab53a1bbb
Thanks for letting me know, I've just rebuilt libspectre in F33 too. I got impression that it aas ok in F33 before, sorry.
Thanks for the rebuilds. We had no reports on F33, and a rebuild of libspectre-0.2.9 on F31 solved the "problem" (for a copr build, not released) there, from which I drew the wrong conclusion. Now F32 through rawhide should be fine (and F31 does not have the newer gs).
(In reply to Marek Kašík from comment #13) > Thanks for letting me know, I've just rebuilt libspectre in F33 too. I got > impression that it aas ok in F33 before, sorry. Thank you for the quick fix. I can confirm that both evince and okular work now so I left the corresponding karma in bodhi.
FEDORA-2020-aab53a1bbb has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-aab53a1bbb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab53a1bbb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-aab53a1bbb has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-6ca8e9b5c0 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.