[lsb-discuss] LSB futures tracker: Rendezvous
dirk.hohndel at intel.com
Mon Jun 26 10:32:04 PDT 2006
On 6/26/06 10:22 AM, "Theodore Tso" <tytso at mit.edu> wrote:
> On Mon, Jun 26, 2006 at 10:05:47AM -0400, Jeff Licquia wrote:
>> The Open Printing workgroup has created a generic API called PAPI which
>> should be a better candidate for standardizing, but it is too new, and
>> is not shipping in any current distros. So, the question is: do we wait
>> for PAPI or add CUPS now?
> How desperately are ISV's calling for the ability get the list of all
> printers, and the size and attributes of the paper trays, what color
> paper are in them, whether the paper is 20lb or 24lb bond, whether the
> pages are bunched after imaged or contain pre-punched paper.... (no
> kidding, there are standards that describe all of this; by ECMA about
> 15 years ago IIRC, although I generally try to block it as a bad
> dream :-).
A lot of this is really needed - and perceived as one of the major gaps for
client Linux today.
> If we can wait, something that can easily support multiple backend
> implementations would definitely be desirable. If the CUPS ABI can
> meet that requirement, all very well and good, but it sounds like
> there are concerns that it exposes too much of CUPS internals?
I think we need to wait and understand what actually is the "accepted use"
in the eco-system. What are the distros shipping, what are the apps using
>> As an additional wrinkle, the desktop projects also include APIs for
>> printing, which might also be good candidates for standardizing.
> Which API's? We probably need to be very careful here, and find out
> exactly what the ISV's actually need and in what timeframe. Is it:
> * A way of enumerating all printers so the user can use a
> pull-down menu?
> * A way of enumerating and fetch attributes about printers,
> attributes about print trays, ways of selecting print
> trays, paper colors, etc.?
> * A generic way of print images, polygons, bitmaps, that can
> be imaged on the screen, transformed into postscript
> or PDF, etc.
That's exactly what I mean. Understand the need, and understand what the
different APIs offer and what is widely used / shipped. Not sure this is
quite ready for standardization, yet.
More information about the lsb-discuss