Re: RFC: Refactoring our Printing Stack(s)
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.
Reply to: