[cups] Handling of "Installable Options" in user applications

[Brian Potkin]

On Mon 07 Sep 2015 at 09:27:43 +0200, Michael Weghorn wrote:

> Hi Brian,

Hi Michael.

> On 2015-09-04 18:16, Brian Potkin wrote:
> 
> >Tea4CUPS is worth looking at. The user can set as many options as she
> >wishes but a script will ensure the ones set for the queue will not be
> >overridden. The Debian Wiki might help.
> 
> Thank you for that tip. I had a look at Tea4CUPS and it looks like a really
> useful tool for various purposes.
> 
> As far as I understand it so far, the way to use it to prevent users from
> setting wrong values for "installable options" is similar to the scenario
> described in the section "Enforcing number-up=2 Printing" in the Debian
> wiki:
> 
> 1) Set up a second virtual queue (which the users will send print jobs to).
> 2) Create a Tea4CUPS prehook for that qeue which modifies the printing
> options so that the system-wide settings for "installable options" are sent
> to the "real queue", leave other options as they are.
> 
> This would make sure that wrongly set options are always replaced.
> What I see as a problem here (in addition to a somewhat increased
> complexity) is that the CUPS filter chain would be processed twice for each
> print job (the first time for the "virtual queue", the second time for the
> "real queue"). While this is not a real problem for small print jobs, it
> approximately doubles the time needed for large print jobs where processing
> the filter chain takes a lot of time (we have some cases where a single run
> takes more than half an hour).
> This is because Tea4CUPS (as I understand it after reading the Debian wiki
> article) only comes into action after the CUPS filter chain has been
> processed. When processing the CUPS filter chain for the first time, the
> user-given options are used for all filters - which means that the
> potentially wrong options for the installable options are taken into account
> and thus make it into the file that would be sent to the printer. Only after
> the second run of the filter chain (which is triggered by the Tea4CUPS
> script), the file can safely be processed by the real CUPS backend.
> 
> Or do I miss something here and there is a better way of doing it?

The virtual queue is set up as a raw queue. My guess is that the processing
time would not increase significantly.
 
> What might also be a bit confusing is that the printer options are still
> shown in the printing dialog and can be changed by the users (though they
> are not applied in the end), but that is probably not a big problem. The
> most important thing is to avoid problems with the real hardware.

Because the users print to the virtual queue and it is raw they will not
be presented with any PPD-specific options in an application's print
dialogue or with lpoptions. You might see this as an advantage or not.

Regards,

Brian.