CUPS Printing PDF files slow, in Print Queue for minutes at a time

seth · 2024-09-18 18:35:01

ppdFilterPDFToPS: Running command line for pdftops: pdftops -level1 -noembtt -origpagesizes -nocenter -r 600 /var/spool/cups/tmp/1cf9f66f01267 -

Worked, you're generating a level1 postscript.

The log is 78MB, debug info of

D [18/Sep/2024:08:51:04 -0700] [Job 1853] Wrote 8192 bytes of print data...
D [18/Sep/2024:08:51:04 -0700] [Job 1853] Read 8192 bytes of print data...

You might want to reset the debug level, restart cups and see whether that's related to the performance.

Another thing to try when playing w/ the filters is to use mupdf

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=mupdf

Ifff that works and iff it still generates PS1 (you'll likely have to keep the debug enabled to figure), mupdf is WAY faster than poppler or ghostscript, so this might give you a huge performance boost.

TheDoors1967 · 2024-09-23 18:55:15

Hello Seth,

Sorry for this later reply, the project we're working on is taking up all my time. Anyway, I tried to set pdftops default to mupdf but now my printer queue just has the status: "universal filter failed." I'm not sure if this is because I'm missing a package? Ah yes, I was... Okay so here's the steps I took:

1) I installed the mupdf package
2) restarted cups
3) retried the lpadmin command
4) reset the cups debug again
5) restarted cups one more time

I tried another print job, but again the status of the queue just says "universal filter failed". Here's the log I have while sending this print job.
Maybe a restart is needed though... I might have to try that before the end of the day. Regardless, I am actually going to revert my printing environment to how I had it at first before continuing more testing.

seth · 2024-09-23 21:48:44

D [23/Sep/2024:11:10:45 -0700] [Job 1877] WARN: ppdFilterPDFToPS: Level 1 PostScript not supported by mutool.
D [23/Sep/2024:11:10:45 -0700] [Job 1877] ppdFilterPDFToPS: Running command line for mutool: mutool draw -L -smtf -Fps -o- -cgray -r600x600 /var/spool/cups/tmp/34d4366f24ccc
D [23/Sep/2024:11:10:45 -0700] [Job 1877] ppdFilterPDFToPS: Started filter mutool (PID 216389)
E [23/Sep/2024:11:10:45 -0700] [Job 1877] ppdFilterPDFToPS: Unable to execute mutool program: No such file or directory
D [23/Sep/2024:11:10:45 -0700] [Job 1877] Set job-printer-state-message to "ppdFilterPDFToPS: Unable to execute mutool program: No such file or directory", current level=ERROR
D [23/Sep/2024:11:10:45 -0700] [Job 1877] ppdFilterPDFToPS: PID 216389 (mutool) stopped with status 1!

https://archlinux.org/packages/extra/x8 … pdf-tools/
However, pay attention to the first line

Have you tried whether poppler is faster w/ disabled debug?

TheDoors1967 · 2024-09-23 23:55:42

Ohhh sorry, okay.

I installed mupdf-tools now (I did mupdf earlier). I set the debug level down to "warn" (I believe that was the original state?). And I see PostScript 1 isn't supported by mutool, sure, but I didn't have the correct package installed at the time.

I'll try using poppler again this time with the debug level reset.

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=poppler

Aaaand it's still just as slow as it usually is, with the pausing behavior, too.

Next, I tried it with mupdf again

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=mupdf

Restarted cups. And it still takes its time in the queue, and still pausing consistently at the printer.

One more thing, after about an hour, I sent another print job to it, but this time it got stuck in the queue with status message "ppdFilterPDFToPS: Unable to execute mutool program: No such file or directory". Granted, this print job was actually an .odt file, not a pdf. But would that really matter? I had a problem in earlier testing where my .odt prints were coming out with strange symbols. Maybe I can't set this default renderer without causing issues with non-PDF files...

Luckily, I've got a handy line to print my larger pdf files from now on without an issue:

pdftops -level1 <filename> print.ps && lpr -P BC02-Grayscale print.ps && rm print.ps

Maybe I can just write a bash script to automate this and forget about printing from browsers from now on...

seth · 2024-09-24 07:35:19

And I see PostScript 1 isn't supported by mutool, sure, but I didn't have the correct package installed at the time.

No, that's unrelated to the binary not being present.

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=poppler

Sorry, poppler is

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=pdftops

[Edit: just to proove that I'm not just cma, "pacman -Qo pdftops"]

"ppdFilterPDFToPS: Unable to execute mutool program: No such file or directory". Granted, this print job was actually an .odt file, not a pdf.

I suspect that this was left over from before installing mupdf-tools, but libreoffice will likely render and print PDFs that are then subjected to the same chain, not postscript directly.
The performance difference is likely a matter of scale and at some point the ps2 to ps1 conversion the printer seems (that's guesswork based on everything we figured) to exceed its internal memory capacity.

Ideally™ generating PS1 w/ the pdftops filter would be as fast as the workaround script (afaict we've not tested that w/o the cups debugging bloat?)

Last edited by seth (2024-09-24 07:36:51)

TheDoors1967 · 2024-09-25 16:13:49

Hi Seth,

Default renderer has been set to pdftops, sorry about the mistake. I restarted cups and tried a new large pdf file. New behavior update! The queue no longer mentioned the filters. It just says "Connected to printer" and the page count just ticks up at around 1 every 2 seconds. The printer started the job immediately, but because of how slow the Pages are getting generated (I guess) it's still pausing between pages. This is with Debug level set to "warn" now.

Also, .odt files are working fine as well. Overall, I'd say this is definitely faster than what I started with, it's just strange how the print job gets sent this slowly. So far, the fastest method is still to use the terminal to create a .ps file and send that to the printer instead.

EDIT: I just noticed that the print jobs were now in color. This is a no-no for me. I needed these to be in Grayscale. That setting is on the ppd:

sudo cat /etc/cups/ppd/BC02-Grayscale.ppd | grep ColorDevice
*ColorDevice: False

But I think setting the renderer to poppler bypassed this setting. Is there some way I can still change this?

Last edited by TheDoors1967 (2024-09-25 16:26:50)

seth · 2024-09-25 21:40:07

https://github.com/OpenPrinting/cups-filters/issues/169

the Poppler utilities pdftops and pdftocairo have no explicit functionality to convert the incoming PDF into monochrome/grayscale PostScript

Head => Wall.

So we have poppler which can print PS1 but not gray.
Ghostscript which can print gray but not PS1.
And a printer that wants to spray colors and is slow with PS > 1

lpadmin -p BC02-Grayscale -o pdftops-renderer-default=gs

Roling w/ the theory that the printer just runs out of cache on internal conversion when sending huge jobs.
Have you tried to print the file in batches?
Ie. one job for pages 1-100, the next job for pages 101-200, … sth. like that (maybe in batches of 25 pages only)?

TheDoors1967 · 2024-09-25 23:35:04

Hi Seth,

We haven't tested ghostscript just yet. I switched the default renderer to gs and tried another 50 page'r. The job doesn't connect to the printer until it was done with the filters (I assume). But it's still pausing every few pages. My grayscale setting was honored, too. Maybe there's a brave developer out there who has created a renderer that can do PS1 in grayscale.

seth · 2024-09-26 07:27:17

ghostscript is the default you were starting with

Maybe there's a brave developer out there who has created a renderer that can do PS1 in grayscale.

ghostscript once could, but PS1 was discarded because "time"

When you're running your poppler script, see whether

pdftops -level1 -optimizecolorspace <filename> print.ps && lpr -P BC02-Grayscale print.ps && rm print.ps

prints actual grayscale - this was the approach in the patch that then caused https://github.com/OpenPrinting/cups-filters/issues/169 (actually as a workaround because some other rasterizers could not produce grayscale postscript)
I wonder whether the colorspace conversion is also what's slowing down on the printer, though ghostscript can produce 8bpc/grayscale files.

There's also an acroread backend, but the problem is that the linux reader was abandoned a decade ago an I don't really expect those binaries to run at all anymore on modern stacks.

TheDoors1967 · 2024-09-26 16:36:26

seth wrote:

ghostscript is the default you were starting with

Oh Ghostscript is the default? Good to know because I had no idea how to set the default renderer again after testing. I did find though that you could use lpadmin's -R option to reset a given option (gotta remember that one for the future).

The -optimizecolorspace option works for me. So, if I were to keep pdftops as my default renderer, print jobs would be a lot faster, but I would still need to create the grayscale version myself through terminal, so it defeats the purpose.

Could you enlighten me on a couple things though? According to documentation about this printer, linked earlier. It supports PostScript 3, supposedly the fastest of the three. The default renderer is set back to gs. And when I send a job using this:

pdftops -level3 -optimizecolorspace <inputfile> print.ps && lpr -P BC02-Grayscale print.ps && rm print.ps

The print is in grayscale, sits in queue for a while, suddenly and very quickly shows "Connected to printer", disappears, and the printer did not pause while printing, however the largest drawback was the time it was sitting in the queue. Is this why you've been saying the printer likes PS1; the fact that using anything other level1 causes the job to sit in queue for so long?

Next, I tried pdftops as the default renderer again, and used the same script. It also sits in the queue for a while, but not quite as long, and the "Connected to printer" status was not too long, it ticked up to the full 132 pages in the span of about 15 seconds. Fast enough so the printer doesn't pause in the middle of the job. However! it came out in color... Why? I thought that creating the Grayscale version of the file with -optimizecolorspace was enough to make a grayscale image.

seth · 2024-09-26 20:39:52

Is this why you've been saying the printer likes PS1; the fact that using anything other level1 causes the job to sit in queue for so long?

Yeah, it's the original condition, isn't? It takes the printer really long to process anything but PS1?

it came out in color... Why? I thought that creating the Grayscale version of the file with -optimizecolorspace was enough to make a grayscale image.

Because what matters is the filter and that runs "pdftops -level1", but not the "-optimizecolorspace", so the resulting PS makes the printer use color (I assume even for what looks like gray)

Here's a disgusting hack:

D [18/Sep/2024:08:51:03 -0700] [Job 1853] ppdFilterPDFToPS: Running command line for pdftops: pdftops -level1 -noembtt -origpagesizes -nocenter -r 600 /var/spool/cups/tmp/1cf9f66f01267 -

Since cups doesn't seem to call a fixed path you could add a script to /usr/local/bin/pdftops (assuming you've /usr/local/bin in the global $PATH, cups matters, not your interactive shell)

#!/bin/sh
date >> /tmp/wehackedcups # this is just for debugging, to show the script gets called, you can comment or remove it later
exec /usr/bin/pdftops -optimizecolorspace "$@" # this runs the actual pdftops but injects a parameter

Don't forget to chmod ugo+x /usr/local/bin/pdftops, see whether the next print picks this up. Try w/ a small document

TheDoors1967 · 2024-09-30 16:34:40

Hi Seth,

Yes you're right, I figured as much about the PS1 issue, but I wanted to get clarification. Thank you for the explanations.

I created that script and made it executable as instructed. A print job was submitted from Okular, but it didn't come out grayscale. Now, I don't know if it's just because CUPS doesn't use the /usr/ binaries or if you meant for me to submit the job through terminal? Also, assuming we want PS1, shouldn't we also add the -level1 parameter to it?

seth · 2024-09-30 19:13:42

I don't know if it's just because CUPS doesn't use the /usr/ binaries

The "date >> /tmp/wehackedcups" line will show you whether the script got invoked by adding timestamps to /tmp/wehackedcups
Otherwise we'll have to look at the cups log again.

assuming we want PS1, shouldn't we also add the -level1 parameter to it?

The postscript level in the PPD will still be honored.

Your previous test was

pdftops -level3 -optimizecolorspace <inputfile> print.ps && lpr -P BC02-Grayscale print.ps && rm print.ps

does it also come out in grayscale when using the script with -level1 ?

Arch Linux

#26 2024-09-18 18:35:01

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#27 2024-09-23 18:55:15

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#28 2024-09-23 21:48:44

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#29 2024-09-23 23:55:42

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#30 2024-09-24 07:35:19

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#31 2024-09-25 16:13:49

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#32 2024-09-25 21:40:07

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#33 2024-09-25 23:35:04

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#34 2024-09-26 07:27:17

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#35 2024-09-26 16:36:26

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#36 2024-09-26 20:39:52

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#37 2024-09-30 16:34:40

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

#38 2024-09-30 19:13:42

Re: CUPS Printing PDF files slow, in Print Queue for minutes at a time

Board footer