Dear Maintainer,

sending a print job with multiple print files to the cups-pdf printer
does not work as expected.

When trying to print three or more files in one print job, the print job
seems to "hang" and does not disappear any more. Subsequent print jobs
sent to cups-pdf are not processed (possibly wait for the previous
print job to complete).

The following commands can be used to reproduce the described
behaviour:

echo "Hello world" > /tmp/input.txt
lp -d PDF /tmp/input.txt /tmp/input.txt /tmp/input.txt

The print job does not finish and can be shown e.g. using the command
"lpstat".

This also happens when different input files are used.
Printing a single file works OK.

When printing the same file only twice, the print job finishes, but the
created PDF file contains only the first page.


Expected behaviour:
The print job finishes and a PDF file with three pages, each containing
the text "Hello world", is created in the directory "~/PDF/".

When sending multiple files in a single print job, the file passed to
the cups-pdf backend seems to contain all of the single files (converted
to PostScript) concatenated.
cups-pdf stops reading the input file after "the first PostScript file"
has been read.

The following patch disables that behaviour. After applying the patch,
printing multiple files works.
The patch is only meant to demonstrate this behaviour and should be
extended/improved in case it is meant to be included.

However, I do not know whether there are possibly other reasons to
explicitly stop processing the input file after "the first file" has
been processed.
It should also be mentioned that Ghostscript (which is used by cups-pdf)
is basically not meant for merging files, s.a.
http://bugs.ghostscript.com/show_bug.cgi?id=696064.

Best regards,
Michael

Sorry, I forgot to attach the patch to my previous email.
Here it is.

Best regards,
Michael

Michael,

Thanks for the patch. While it was produced against a very old release
of CUPS-PDF (2.6.1), the bug is nonethelss tagged as offering a patch,
until upstream has had a chance to examine it and decide whether it
still applies to the current 3.0.1 version or not.

Martin-Éric

ti 17. marrask. 2015 klo 12.09 Michael Weghorn (m.weghorn@posteo.de) kirjoitti:

Got bit by this on bullseye cups + (backported) sid cups-pdf.

In this case i can only reproduce this with a postscript file,
I'm using the attached one: specifying it thrice hangs the PDF process
below cupsd -l; I managed to unstick it by removing the respective
/var/spool/cups/d$job-* files and restarting cups.service.

In the case of attached, the output (when using just one) is
horrifically mangled, as compared to using something like gv(1)
(or a plain gs -dSAFER -dBATCH -dNOPAUSE  -r600  -sDEVICE=pdfwrite),
but that's another issue, I'm assuming? Or is this some aspect of this
postscript that explodes it both ways? Please advise.

Best,
наб