Created attachment 10133 [details] example file to show the problem I built gs9.09 from source on Fedora 17 x86_64. I tested viewing PDFs though gv, which first runs the PDF through gs pdf2dsc to find the list of pages. pdf2dsc from gs9.07 and earlier worked on all of my PDFs, but in gs9.09, it fails with "Error: /invalidaccess in --setpagedevice--". I checked that pdf2dsc.ps and pdf2dsc are the same as in gs9.07. Commenting out the line below in pdf2dsc.ps fixes the error, but gs9.07 works with that line enabled. systemdict /.setsafe known { .setsafe } if I have attached an example file. I have a log below. William /tmp/x/ghostscript-9.09$ ./bin/gs -v GPL Ghostscript 9.09 (2013-08-21) Copyright (C) 2012 Artifex Software, Inc. All rights reserved. /tmp/x/ghostscript-9.09$ ./bin/gs -dNODISPLAY -dQUIET -dDELAYSAFER -sPDFname=/tmp/cyan.pdf -sDSCname=junk.tmp ./lib/pdf2dsc.ps -c quit Error: /invalidaccess in --setpagedevice-- Operand stack: false false --dict:1/1(L)-- --nostringval-- --dict:60/60(ro)(L)-- --dict:1/1(L)-- --dict:2/61(G)-- InputAttributes --dict:65/65(L)-- --dict:2/61(G)-- InputAttributes --dict:65/65(L)-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1909 0 3 %oparray_pop 1908 0 3 %oparray_pop --nostringval-- 1862 2 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- --nostringval-- Dictionary stack: --dict:1168/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is global Current file position is 1899 GPL Ghostscript 9.09: Unrecoverable error, exit code 1
Surely, the time to test would be in the release candidate, rather than after the release......?
Commit 39b494d41a814e6b27a5828030e58e0b239044fb removes the line. This is a hacky script which relies on using undocumented internal operators, the resulting 'PostScript' also relies on using parts of the PDF interpreter which are likewise undocumented and subject to change without notice. I'd have to recommend you find a different solution to whatever problem this is intended to solve. Very likely I will remove this script altogether in the near future.
Thanks! gv does not know how to parse PDF and uses pdf2dsc to find the list of pages and the size of each page. google shows that a number of applications script pdf2dsc, for example, latex and xemacs. Is there anything that you can recommend to replace pdf2dsc? I will subscribe to gs-devel -- is that where the release candidates are announced? Are the release candidates posted anywhere? I just made a clone of git://git.ghostscript.com/ghostpdl.git but it built only xps/obj/gxps and does not seem to build gs. Can I build gs from it, or is there another url for the ghostscript repository? William
(In reply to comment #3) > gv does not know how to parse PDF and uses pdf2dsc to find the list of pages > and the size of each page. google shows that a number of applications > script pdf2dsc, for example, latex and xemacs. Is there anything that you > can recommend to replace pdf2dsc? Use ps2write to convert into DSC PostScript ? Or use a better PDF viewer. I'm frankly disturbed that applications are dependent on a script which not only uses undocumented internal functions, but produces 'PostScript' which relies on more internal machinery of Ghostscript. > I will subscribe to gs-devel -- is that where the release candidates are > announced? Yes, that's the place. > Are the release candidates posted anywhere? As binaries ? Not usually (though Chris did build Windows ones this time), just as source. > I just made a clone of git://git.ghostscript.com/ghostpdl.git but it built > only xps/obj/gxps and does not seem to build gs. > Can I build gs from it, or is there another url for the ghostscript > repository? That should be all of it. You need to run configure though, and the GS makefile is in the gs sub-directory, the other tools are separate as yet.
The ghostpdl git has the gs sub-directory and you can run autogen.sh to build the appropriate Makefile and make in the gs directory. For example, cd gs ./autogen.sh > config.log 2>&1 make -j5 > make.log 2>&1 BTW, .setsafe *is* important since the psd2dsc shell script starts gs with -dDELAYSAFER so the pdf2dsc.ps can open the file without the restrictions of SAFER mode, but then run the input file in SAFER mode. If a malicious PS file is sent to pdf2dsc and it is run without SAFER mode, it could wreak havoc. Reopening because removing the .setsafe breaks the intended security
Thanks for reopening it and for the commands to build gs from git. I must have missed the autogen.sh file. The problem with ps2write is that the resulting ps could end up much larger than the original pdf, and the time to open the first page in gv could be potentially very long. gv isn't the prettiest viewer (I usually read pdf documents with atril, the MATE desktop version of gnome 2 evince) but it has an easy way to open a small section of a document with a very high magnification and it can be built easily on any system with libX11. If I test a gs release candidate, I would build it from source. I do not need binaries. I did a git bisect. The commit that caused the problem is 939e32ff3c8841507aed80435269457f3caac6f5 William
Commit ae930279498a5961fcf5d70ffe86864883609cbc ought to fix this, hopefully completely, but with code this spaghetti-like I have little confidence now. It would be useful if people would test it.
Thanks! I tested the patch, and it works for me. William