Hello, On May 19 18:28 John Layt wrote (excerpt):
Once Cups has the document I believe it queries the printer driver to see if it supports multiple copies from a single upload and the printer has enough memory for the file.
Usually there is no bidirectional communication between the various filters which convert the initial print job data into printer device specific data, the backend which sends the final data to the printer device, and the printer device. Usually when print job data is processed it is a unidirectional pipe of filters and final stage the backend which sends the final data also usually in an unidirectional way to the printer device. See http://en.opensuse.org/Concepts_printing and for some details http://en.opensuse.org/SDB:CUPS_in_a_Nutshell and for more details http://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS and http://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS I wrote "usually" above because CUPS provides cupsBackChannel and cupsSideChannel functions for bidirectional communication, see http://www.cups.org/documentation.php/doc-1.4/api-filter.html but the usual filters and backends do not use it - at least not in the way you initially assumed. For printer device specific options PPDs are used, see http://en.opensuse.org/Concepts_printing and for some details http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Note that bidirectional communication with a printer device depends on the particular printer model. There is no such thing as a general standard how to communicate in bidirectional way with a printer device (perhaps except some generic SNMP stuff - but even this fails often, see below). Therefore for each kind of printer device the matching bidirectional communication must be implemented. This is again something which is (of course) not done by volunteers. One must pay someone to do such ugly work. For example HP pays their employees of their HPLIP team to implement at least some basic bidirectional communication for their HPLIP driver software, see http://hplipopensource.com/node/125 But it is mandatory that filters and backend must not depend on bidirectional communication with the printer device. Think about a connection to the printer device which does not support bidirectional communication, for example - the usual printserver boxes which support only plain port 9100 and LPD but not the generic SNMP stuff (see above) - when the printer device is not directly accessible but "hidden" behind whatever kind of remote print queue or remote printer share under a different operating system where a print job which comes in from CUPS gets only queued and is actually printed at any time later so that there cannot be a bidirectional communication between the CUPS filters/backend and the printer device. Because printer device specific printing options are done via PPDs, there is no need for bidirectional communication with the printer device to find out device specific printing options. Bidirectional communication with the printer device is only needed to find out what the current printer device state is (idle, printing, out of paper, paper jam, toner/ink low, out of toner/ink, ...). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org