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
  • 912
  • 2
  • 8
  • 19
  • I made a few tests with multiple files to Boomaga printer driver and I got an **Error on 551: Can't read genNum** message. You can try to print the files like this: `cat alpha.txt beta.txt | lp`. – FedKad Dec 10 '22 at 10:20
  • @FedKad: Unfortunately, the solution with `cat` doesn't work if I'm printing a mixture of .txt and .pdf files. Also, I'll have to manually insert page breaks between the files. – oz1cz Dec 10 '22 at 10:26
  • Check if you have a shell alias for that command that maybe doesn't properly forward all arguments that it gets to the underlying command. That happened to me more than once. – HuHa Dec 11 '22 at 01:12
  • @HuHa: That can't be the problem. As you see, the `lpq` command lists the file `alpha.txt`, but `beta.txt` is the file that's actually printed. So somehow the print system knows about both files. – oz1cz Dec 11 '22 at 13:22
  • Could you check `which lp` and try `lp -- alpha.txt beta.txt` – user.dz Dec 13 '22 at 12:51
  • 2
    Please try and see if `for f in "alpha.txt" "beta.txt"; do lp "$f"; done` makes a difference ... i.e. using the loop to send each file as a separate single argument. – Raffa Dec 13 '22 at 13:25
  • 1
    @user.dz: `which lp` prints `/usr/bin/lp`. Using `lp -- alpha.txt beta.txt` makes no difference. @Raffa: Issuing two `lp` commands causes both files to be printed; and this is, of course, a useful substitute. However, the documentation for `lp` says that it should be possible to print multiple files using one command, so I wonder why it doesn't work. – oz1cz Dec 13 '22 at 15:05
  • Please see my additions to the original post. – oz1cz Dec 13 '22 at 15:23
  • 1
    It seems that `alpha.txt` is not really a plain text file and it is damaged … "missing external reference” usually happens with binary files e.g. images … Test with `echo "text 1" > file1.txt && echo "text 2" > file2.txt && lp file1.txt file2.txt` and see how it goes. – Raffa Dec 13 '22 at 16:09
  • 1
    @Raffa: `alpha.txt` is absolutely a plain text file. I created it exactly as you suggest, and a hex dump of the file shows it as entirely a plain text file. Anyway, the error message is not "missing external reference" but "xref not found", which could be an internal reference created by `gstoraster`, if that is indeed the problem filter, as I suggested in my latest addition to the post. – oz1cz Dec 13 '22 at 16:32
  • "xref" is not necessarily "external reference". It can simply mean "cross reference". – oz1cz Dec 13 '22 at 16:49
  • Oh, I see … could be corrupted printer/spooler … So probably removing and reinstalling both cups and ghostscript might fix it. – Raffa Dec 13 '22 at 16:50
  • 3
    @Raffa: I doubt it. I recently reinstalled everything on my computer, and I had the problem both before and after the reinstallation. Anyway, I've discovered that CUPS has a mailing list for this kind of problem. Maybe I should try there. Anyway, thank you for your kind effort. – oz1cz Dec 13 '22 at 16:53
  • @oz1cz Please, update this Q&A with more information as it becomes available. Obviously, it looks that there is bug in the `lp` software. – FedKad Dec 15 '22 at 10:21
  • @FedKad: I will. I've asked the same question on a CUPS mailing list, but so far I've had no reply. – oz1cz Dec 15 '22 at 15:52

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
  • 912
  • 2
  • 8
  • 19