Re: Gtk+ printing dialog highlevel thoughts

[Norm Jacobs <Norm Jacobs Sun COM>]

Alexander Larsson wrote:

> On Wed, 2006-01-25 at 23:51 -0600, Albert Chin wrote:
>  
>
> > On Thu, Jan 19, 2006 at 10:39:13AM +0100, Alexander Larsson wrote:
> >    
> >
> > > On Wed, 2006-01-18 at 19:39 -0500, Michael Sweet wrote:
> > >      
> > >
> > > > Alexander Larsson wrote:
> > > >        
> > > >
> > > > > (cc:ing some people who I think might be interested in this)
> > > > > 	
> > > > > I've just started looking at doing a printing dialog for Gtk+
> > > > > 2.10. For some background thoughts from owen, see: 
> > > > > http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html
> > > > >          
> > > > FWIW, both Windows and MacOS X provide APIs for accessing the list of
> > > > available printers, etc., and the CUPS API is also available on
> > > > MacOS X.  WRT Linux printing, CUPS is pretty much ubiquitous, and
> > > > failing that you can standardize on PAPI (the SourceForge library
> > > > apparently supports CUPS, LPR, and Solaris lp - check with Norm
> > > > Jacobs for details...)
> > > >        
> > > I think relying on CUPS might be good enough. Opinions on this? Does
> > > e.g. solaris ship CUPS?
> > >      
CUPS doesn't ship with several closed source and open source platforms
including Solaris.  Some of these platforms ship GTK or provide it
as an add-on.  In my opinion, forcing the customer to replace their
print service with CUPS to use GTK is bound to cause resistance.  It's
not that I don't think that CUPS is/can be a fine solution in many 
situations.
It's just not the only solution and it's also not necessarily a system 
vendor
supported solution on several platforms.

> > So older systems like Tru64 UNIX, HP-UX 11.00, 11.11, AIX 5.1, 5.2
> > will require CUPS to be installed? Ugh.
> >    
>
> I guess we could do a very simple traditional "enter lpr command
> line"-entry style dialog for systems without cups. 
>
>  
This is part of why the PAPI was created.  It is intended to provide
applications (and toolkits) a print service independent API to printing.
It allows you to either use or replace the platform's native print
service without orphaning a set of applications or toolkits.

The current implementation on SourceForge supports interaction with
IPP, RFC-1179 (lpr/lprng/...) print servers.  There is also support is 
Solaris
LP in OpenSolaris.

As Mike pointed out, it provides basic print service interaction job
submit/cancel/query, queue enumerate/query, as well as, several other
operations on jobs and printers.  It also provides some printer capability
data, but it doesn't yet provide the full set of data available from a 
printer's
PPD file or capabilities data store.

Improving the capabilites support been on the list for a while.  A couple
of days ago, I had a conversation with someone at work that is going to
be solving this over the next month or two.  Now would actually be a good
time to provide input on exactly what data you want to see (groupings,
capabilities, comment strings, ...) and how it would be best for you to
access them (a blob of string encoded data, a structured tree, a series
of functions to walk through an underlaying datastore, ...)

         -Norm