我尝试从命令行打印两个文件:
$ lp alpha.txt beta.txt
该lpq
命令给出以下输出:
$ lpq
HP_OfficeJet_Pro_6970_7BE7A4 is ready
Rank Owner Job File(s) Total Size
1st claus 56 alpha.txt 2048 bytes
这里仅提到了文件alpha.txt
。但是,实际上只打印了文件beta.txt
。alpha.txt
不打印。
这可能是什么原因呢?
我正在运行带有 CUPS 2.4.1 的 Ubuntu 22.04.1 LTS。
更多信息
如果我用来lp
打印多个文件,则会出现以下消息/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
更多信息 2
日志中的文件名以 12345 开头。这种巧妙的模式纯属巧合。反复尝试表明,文件名的前 5 位数字似乎是gstoraster
打印过程中运行的 CUPS 过滤器的 PID 的十六进制值。因此,问题可能出在该过滤器上。
答案1
回答我自己的问题:
我在 CUPS 邮件列表中发布了这个问题,并得到了 Helge Blischke 的回答:
好吧,我不完全明白这里发生了什么,但我至少有一个假设,我会尝试在这里解释。
我从您的日志文件中了解到:
— 您的打印机是使用隐式类的模拟设置的(由 openprinting 开发,以使 cups 1.x 中实现的隐式类的功能在 cups 2.x 中可用),基于 cups-browsed 的功能。
这种方法至少对我而言似乎相当复杂,其关键特性是这里使用的后端“implicitclass”通过对每个作业文件执行完整的过滤链来收集相关打印机的所有作业。
— 这意味着例如对于 PDF 文件(cups-filter 策略是使用 pdftopdf 过滤器将所有要打印的文件至少中间转换为 PDF,根据我的经验,它会在每个 PDF 文件中附加一个额外的 EOF 字符(我认为是 ^Z)。
— 在由 implicitclass 后端执行的过滤器链中的某个地方,PDF 由 QPDF 库中实现的例程处理,这会导致由中间 ^Z 字符引起的 PDF 错误消息 — 这至少是我从各种消息中推断出的。
由于我自己不使用 cups-filters 包(即使在我的 Linux 机器上也不使用),所以我没有机会进一步研究这个问题。但我认为我的论点不可能完全错误。
所以,显然,这是 CUPS 中一个相当复杂的错误,我只能忍受它。