[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Refactoring our Printing Stack(s)



Le dimanche, 16 octobre 2011 17.54:37, Roger Leigh a écrit :
> 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.

Good point, thank you.

The thing is that I have seen no sign from maintainers of non-cups spoolers 
and I'm willing to do the job only if it's well-defined and serves a purpose. 
Without input from those, I can't know what is needed.

> > * 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?

Agreed for the consistent naming. Then, to link printers and driver packages, 
there is the DEP-11 [0] that is currently under discussion that would 
certainly be of use for this (thanks Paul for the pointer).

[0] http://lists.debian.org/debian-project/2011/10/msg00043.html

So I would somehow wait on the outcome of this to add metadata to the -
printing packages.

Cheers,

-- 
OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: