9

I try to print two files from the command line thus:

$ lp alpha.txt beta.txt

The lpq command gives this output:

$ lpq
HP_OfficeJet_Pro_6970_7BE7A4 is ready
Rank    Owner   Job     File(s)                         Total Size
1st     claus   56      alpha.txt                       2048 bytes

Here, it mentions only the file alpha.txt. However, only the file beta.txt is actually printed. alpha.txt is not printed.

What might be the reason for that?

I'm running Ubuntu 22.04.1 LTS with CUPS 2.4.1.

FURTHER INFORMATION

If I use lp to print more than one file, these messages appear the /var/log/cups/error_log:

W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95: file is damaged
W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95 (offset 14802): xref not found
W [13/Dec/2022:16:22:19 +0100] [Job 61] /tmp/12345639a6b95: Attempting to reconstruct cross-reference table

FURTHER INFORMATION 2

The file name in the log starts with 12345. This neat pattern is a coincidence. Repeated attempts show that the first 5 digits of the filename appear to be the hexadecimal value of the PID of the gstoraster CUPS filter that runs as part of the printing process. So perhaps, the problem lies with that filter.

oz1cz
  • 942

1 Answers1

2

Answering my own question:

I posted the question on the CUPS mailing list and got this answer from Helge Blischke:

Well, I do not completely understand what is going on here, but I at least have a hypothesis I’ll try to explain here.

What I’ve learned from your log file is:

— Your printer is set up using an emulation of implicit classes (developed by openprinting to make the functionality of implicit classes implemented in cups 1.x available in cups 2.x) based on the functionality off cups-browsed.

This approach seems - to me at least - rather complicated, and the key feature is that the backend "implicitclass", which is used here, collects all jobs for the printer in question by executing the complete filter chain for each job file.

— This implies e.g. for PDF files (the cups-filter strategy is to convert all files to be printed at least intermediately to PDF using the pdftopdf filter, which - to my experience - appends an additional EOF character (^Z, I think) to each PDF file.

— Somewhere in the filter chain executed by the implicitclass backend the PDFs are processed by routines implemented in the QPDF library, which leads to PDF error messages caused by the intermediate ^Z characters — that is at least what I deduct from the various messages.

As I myself do not use the cups-filters package (even on my Linux box I don’t), I have no chance to digest further into this problem.but I think my thesis cant’t be completely wrong.

So, apparently, it's a rather complicated bug in CUPS, and I'll just have to live with it.

oz1cz
  • 942