Hi Frédéric and Adam, On Tue, Mar 02, 2021 at 01:33:04PM -0500, Frédéric Brière wrote: > Package: xpdf > Version: 3.04+git20210103-1 > Severity: normal > > Attempting to print any (non-trivial) PDF document with xpdf > 3.04+git20210103-1 results in a "No pages found!" CUPS error. > Downgrading to 3.04-14 fixes the issue. > > This seems to be caused by a broken PostScript output; printing to a > file and opening it with gv results in the following error: > > Error: /undefined in xpdfGPL Ghostscript 9.53.3: Unrecoverable error, > exit code 1 > > Operand stack: > > 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-- > Dictionary stack: > --dict:733/1123(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)-- > Current allocation mode is local > Last OS error: No such file or directory > > > As an example, I'm attaching pre- and post-bug PostScript versions of > the Debian Reference Card.
I notice that this does not happen when xpdfrc defines a psLevel to use (any of the six levels mentioned in the manpage will do). The xpdfrc manpage claims the default psLevel is level2. Perhaps xpdf needs to set that explicitly? The postscript that causes this gs error claims to be LanguageLevel: 3, the file size is even smaller than what a psLevel of level3 or level3sep generates. Adam, do you know if this is xpdf failing to set a default, or poppler (20.09.0 in Debian testing/unstable) being buggy? Florian
