我需要打印 40 份 21 页（双面）彩色 PDF 文档。从我点击“打印”到打印机开始打印，花了 40 分钟。
当我打印一份副本时，它的启动速度要快得多。似乎我制作的副本越多，我点击打印和开始打印之间的延迟就越长。为什么会这样呢？ CUPS 是否正在向打印机发送 840 页文档？难道打印机不应该只接受一个文件并“知道”制作副本吗？
答案1
难道打印机不应该只接受一个文件并“知道”制作副本吗？
这需要打印机有足够的 RAM 来 a) 存储整个文档，b) 仍然有足够的可用内存以全分辨率渲染打印作业的任何单页。即使这些事情是真的，CUPS 也需要告诉打印机去做。如果 CUPS 不确定打印机能否执行此操作，CUPS 确实会向打印机发送 840 个单独页面的打印作业。
另一种可能性是打印副本未整理的，即首先打印第一个双面页的 40 份，然后打印第二个双面页的 40 份，依此类推。这将需要用户手动将文档的每个副本放在一起，如果页面很多，这可能会令人恼火且容易出错。这就是为什么有副本整理的（即首先打印副本 #1 的所有页面，然后打印副本 #2 的所有页面，等等）只要有可能，往往是现代打印机驱动程序中的默认设置。
答案2
就我而言，这是 GhostScript 效率低下的原因。
我从旧的 Raspberry Pi 1 向我的 EcoTank 喷墨打印机发送了 100 份单页 PDF 文档。在打印机开始接收数据之前的漫长时间内，Pi 上的 GNU/Linuxtop和ps命令占用了近 100% 的 CPU正在这样做：
gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r360x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=841 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=0 -dcupsCompression=1 -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c <</.HWMargins[8.400000 8.400000 8.400024 8.399963] /Margins[0 0]>>setpagedevice -f -_
当我尝试暂时/usr/bin/gs用捕获其输入的脚本替换时，我确认 CUPS 已生成一个 100 页的 PDF 文件（使用pdftopdf），并要求 GhostScript 对其进行光栅化。
换句话说，CUPS 要求 GhostScript 将 100 个页面转换为位图。 CUPS 似乎不知道它可以要求 GhostScript 只转换一页并将结果发送到打印机 100 次，而 GhostScript 似乎也不知道它可以这样做它是只渲染第一页并重复该结果 100 次。 GhostScript 可能可以在这方面做得更好，因为 CUPS 为其制作了 100 页的 PDF 文件做过告诉它重复使用上一页中的对象 100 次，但 GhostScript 不够聪明，无法在不花费大量 CPU 重新渲染它们的情况下做到这一点。
（不，用/usr/bin/gs在一页上调用真实 GhostScript 并重复其结果 100 次的脚本来替换是行不通的：它将需要对其二进制标头进行低级更改，以使 CUPS 接受额外的副本。）
如果我创建 100 个单独的打印作业
for i in {1..100}; do lp doc.pdf; done
然后它开始打印的速度要快得多，但是当 Pi 重新渲染页面时，每个副本之间会有短暂的延迟。如果我创建 20 个打印作业，每个作业 5 份，
for i in {1..20}; do lp -n 5 doc.pdf; done
gs每批 5 个 while运行之间有较长的延迟。 CUPS 显然不够先进，无法gs在第一个作业完成之前开始运行下一个作业。
如果我们对 CUPS 或 GhostScript 源代码做更多的工作，我们也许能够让它识别这种情况并更多地重用其计算。不幸的是，这种额外的开发将花费我们更多的时间，而不仅仅是等待它，或者通过连接具有直接驱动打印机的软件的机器来绕过 CUPS。