CUPS Filter Versus Backend for Hold/Release Queues

When hold/release has been enabled for a given print queue, the typical behaviour observed is very much as you’d expect; at the operating system level, the print queue will appear to contain all print jobs that have been printed to that queue which have yet to be released, each of them held in a “paused” state.

However, some print queues on Mac or Linux servers exhibit different behaviour. No matter how many print jobs are sent to these queues, only the earliest of these will appear to be held in the queue. When that print job is released, the print job which was chronologically “next in line” then appears in the queue, held and ready to be released.

It follows that if your users submit a number of print jobs to a queue of this variety, it will seem as though all but the first print submitted have gone missing. These prints will then only reappear as available to be released when all preceding prints have each been released in turn. Hardly ideal behaviour!

Hmm Well Okay But Why?

A service known as CUPS is the printing system employed by all Mac OS X machines, as well as almost any distribution of Linux, and is therefore the service with which PaperCut must interact in order to track and control printing on these platforms. When PaperCut monitoring is enabled for a print queue managed by CUPS, we are actually installing ourselves as one of two types of CUPS entities; a filter, or a backend. The default (and preferential) of the two is for PaperCut monitoring to be enacted via a CUPS backend.

However, some printer drivers are implemented such that they don’t play nice with our CUPS backend. When we install ourselves as a CUPS filter, it’s because the particular driver in use for these queues is one for which PaperCut must employ a workaround of sorts in order to ensure compatibility; if we know that we can’t cooperate with a driver as a CUPS backend, we try as a CUPS filter instead!

The tradeoff with this change is that we are now further upstream in the CUPS printing workflow, and can exert less direct control over the print job passing through that queue. In a little more detail, print jobs would normally proceed through a series of filters as they pass through the operating system’s print queue before flowing out of CUPS and into our backend, whereupon we can move the jobs around in a hold/release queue at will. When we are installed as a filter, we now sit ahead of where the job would typically leave CUPS’ control, so to provide any sort of hold/release capability at all, we need to hold the job whilst it remains within CUPS’ purview. Because of this, CUPS can still see that the job has yet to print, and so will not proceed to processing the next job along the queue until it leaves. The result? Some hardly ideal behaviour!

But I Really Like Hold/Release Queues…

If one of your print queues is giving you this particular grief, then your best bet will be to try out an alternate driver for it. For example, on a Mac OS X server, you could try setting up your hold/release queue using Apple’s inbuilt “Generic PostScript Printer” driver, and seeing if the printing options and output are sufficient for your environment. Another avenue would be to try other drivers from the vendor themselves; perhaps their PostScript variant for your model device, replacing the PCL variant, or maybe even a driver intended for a different model which is quite similar to your own. With any luck, you can find a combination which provides the functionality you need, from end to end.

Can’t use any other drivers? Is your driver The One and Only? Get in touch with us at ( http://support.papercut.com ), and we’ll guide you through collecting some diagnostic items. These items may shed some light on if anything can be done!