On Fri, Oct 14, 2011 at 03:52:55PM +0200, Didier Raboud wrote: > In short, I might summarise the issues list (as I see it) as following: > > * The printing stack seems more and more cups-specific (think pyppd-) > compression in /usr/lib/cups/driver, etc). About that I would like to hear > opinions of non-Cups print spoolers maintainers: is that true, is that a > problem?
It's a problem, to a certain extent. I don't think that lack of features in spoolers other than CUPS should prevent the use of CUPS-specific features. It's notable that the CUPS printing pipeline e.g. pstops, pstoraster and rastertoxxx could be used *directly* by any other spooling system. From this POV, I think it would make sense (long-term) for some CUPS components to be split from the main CUPS daemon and the other spoolers adapted to automatically use them. This would mean drivers wouldn't then be "CUPS-specific", and we wouldn't need multiple means of configuring the same drivers for different spoolers e.g. the complex beast that is Foomatic. > * There is no consistent naming across drivers, printer databases, spoolers, > etc, leading to a namespace chaos. > * Dependencies don't seem consistent (see the wikipage). These should be fixed fairly simply: let's just define a consistent set of naming conventions and migrate the relevant packages. It would be nice to have a means of mapping a given printer model to required package(s) to support and configure printing, perhaps using the OpenPrinting/Foomatic database? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
