I have several LaTeX documents for creating booklets that are run through the following pipeline: <LaTeX stuff that produces PS> | psbook | psnup -s1.0 -pletter -l -Pstatement -2 > $*.ps; ps2pdf -sPAPERSIZE=letter -dEmbedAllFonts=true $*.ps; psbook and psnup both run just fine, but ps2pdf is not happy when it runs (see "Additional Information" for the error message). The same error is exhibited if I attempt to view the psbook/psnuped file using GS. (If I view the PS file before it goes through psbook/psnup, everything works just fine.) On the other hand, if I use the binary versions of these programs from a Debian-based distribution (say, Ubuntu), ps2pdf is happy with the output and produces the booklet, exactly as I desire. I am currently playing around with the Debian source for this package to see if I can identify which of their patches fixes this problem; will report back if I find something. Reproducible: Always Steps to Reproduce: 1. Run a PS file through any of the psutils programs. Actual Results: Psutils alters the file so that it is no longer acceptable to Ghostscript (see GS error message below). Expected Results: Psutils should output acceptable PS. After the file goes through psutils, ps2pdf yields the following error: Error: /rangecheck in --get-- Operand stack: names --nostringval-- 1 2577 --nostringval-- 9 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1126/1686(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)-- --dict:53/72(ro)(G)-- --dict:10/30(L)-- Current allocation mode is local Last OS error: 2 Current file position is 8179 GPL Ghostscript 8.54: Unrecoverable error, exit code 1
As a temporary workaround/alternate option, I have created an ebuild for installing psutils using the Debian source and patchset; according to my naming the package would appear as app-text/psutils-debian in the Portage tree. It blocks if psutils is already installed. The binaries produced by this ebuild solve the indicated problem for me on AMD64 (Opteron, Athlon 64 X2) and x86 (Pentium M).
Created attachment 125940 [details] Alternate ebuild for psutils using complete Debian source/patches
The versions of psutils included with TeXLive fix this problem. I am not sure whether to keep the bug open, or close it.
Correction: it appears that psutils is not included with TeXLive; thus, a working version of the psutils package is still needed.
hmm that's weird, I cant get it to do it wrong. Could you please provide me a postscript file and a command that would make the postcript invalid and unusable by gs ? (which ghostscript are you using by the way?)
No response since 2008