[cups.development] [RFE] STR #1271: querying a "ppd" for a printerclass

[Helge Blischke]

Patrick Gosling wrote:
> 
> [STR New]
> 
> At present, applications such as kprinter, if pointed at a CUPS printer
> class, fail to deal sensibly with asking the user for printer settings,
> because there's no obvious analogy to requesting /printers/printername.ppd
> .
> 
> CUPS' "lpoptions -l" command appears to cope better, but in practice
> appears to just query the first available printer in the class.  This
> isn't completely unreasonable as a kludge, and may be the quickest way of
> getting half-way decent behaviour out of kprinter.
> 
> However, I _think_ that there's a case to be made for CUPS supporting a
> "GET /classes/classname.ppd" request, with the ppd in question being
> generated by the cupsd by selecting only those parts of the individual
> printer.ppds that are common to all the printers.
> 
> Link: http://www.cups.org/str.php?L1271
> Version: 1.2-feature

Not a real solution but a possible workaround if this feature is vital to you:

you could build a backend that only forwards a print job to a different destination
(which then well may be a class). This way you could set up "relay printers" that
behave like real printers as far as apps like kprinter ar concerned but in effect
print to a class.

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de