ke 29. syysk. 2021 klo 10.11 Andre Heider ([email protected]) kirjoitti: > Did some more digging since I reused this bug because I thought it's the > same issue...
Thanks! > If you set the GSCall config to the default value but append > "1>/tmp/gs.out 2>&1" you can see an error in that file: > > --- 8< --- > Error: /nocurrentpoint in --currentpoint-- > Operand stack: > (--) 80 > Execution stack: > %interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > --nostringval-- false 1 %stopped_push 1990 1 3 > %oparray_pop 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop > 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop > .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 > %stopped_push --nostringval-- --nostringval-- > Dictionary stack: > --dict:736/1123(ro)(G)-- --dict:0/20(G)-- --dict:89/200(L)-- > --dict:63/140(L)-- > Current allocation mode is local > Current file position is 10444 > GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1 > --- 8< --- > > The reason it fails with lp but succeeds with the manual gs cmdline is > that cups preprocesses the input file. If you use "GSCall echo %s %s %s; > cp %s /tmp" it'll copy the actual file used for cups-pdf to /tmp, for > which you then get the same error if you manually use the gs cmdline on it. > > I don't know enough about the printing stack/postscript to tell if > that's fixable, but it all sounds like a corrupt ps file to me. This is a Ghostscript error. Reassigning. Martin-Éric
