"intelligent" load balancing or duplex detection

[Elvin Lee]

I had considered writing a backend to perform duplex detection, but I 
could not discern a way to "select" a printer in the class to perform 
the print job. Could you enlighten me on this?

Basically, I was worried that even if the backend could properly detect 
that a print job required duplexing, and then sent it to the correct 
printer, wouldn't CUPS still perform a "dumb" load-balance at the 
appropriate time and select a printer from the class to process the job?

Perhaps if you made your backend available, I could use it as a model to 
build mine. :)

Elvin


Helge Blischke wrote:
> Elvin Lee wrote:
> 
>>Robert E A Harvey wrote:
>>
>>>Elvin Lee wrote:
>>>
>>>
>>>>The problem, of course, is that only one of the printers support
>>>>duplexing. Is there a way that I can configure cups on the server to
>>>>automatically send duplex jobs to one of the printers in the class,
>>>>rather than choosing between the two?
>>>
>>>
>>>I've read the official reply, but it's got me thinking.  Are these
>>>network connected? they sound like it, being an 'N' product.
>>>
>>>It might be possible to create a totally separate duplex queue, pointing
>>>separately  to the duplex machine, and print to that?  It would
>>>certainly work with jetadmin on Solaris, I've done that sort of thing -
>>>an A4 queue and an A5 queue onto the same machine.
>>>
>>>Never tried it with CUPS - my system was quite straightforward, two
>>>printers each with a unique queue, 'cos they were not physically close.
>>
>>Yes, they are networked, and it is possible to have a duplex queue and a
>>non-duplex queue. However, I would like to ideally have the feature I
>>described previously because users will inevitably try printing duplex
>>jobs to the non-duplex queue (or vice versa) and then we're back to
>>square one.
>>
>>Of course, the alternative would be to hack the PPD files to disable the
>>ability to print duplex jobs to the printers in the non-duplex queue...
>>Thus if they wanted to print duplex, they would have to select the other
>>queue. This is a potential workaround, but not really a substitute -- I
>>feel it lacks the functionality and robustness of the solution I
>>suggested. But I may have to set up something of this sort as Fall
>>quarter is rapidly approaching...
>>
>>Thanks for taking the time to write. All help is appreciated. :)
>>
> 
> A workaround I've used several times for similar issues is to write a
> special
> (scripted) backend that checks the job for duplex printing and then
> forwards the
> job to the correct physical printer.
> If you are sure that duplex printing is only selected by job attributes,
> it is quite
> easy to check the option string on the command line, otherwilse you'd
> have to feed
> the job through Ghostscript (the nulldevice for speed) and intercept the
> setpagedevice
> operator and the level1 compatible things (like duplexmode etc; see the
> PPD).
> 
> Helge
> 
>