Re: [Gnome-print] lp or not lp?

[Ben Woodard <ben valinux com>]

For the moment, what happens after this is basically that the program
who would like to print, creates a pipe, forks and then exec's
lpr. Some more clever programs actually let you specify the command
line but it is still basically a fork and exec.

I personally would like a nicer API to printing but so far none has
emerged as a standard and so I started creating my own as part of my
ongoing effort to create a new and improved printing system for unix
like operating systems.

Right now the header file that I've been working with is:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lpr/lpr/libprintsys/src/Attic/printsys.h?rev=1.1.2.3.4.16&content-type=text/vnd.viewcvs-markup&only_with_tag=gnulpr-2_0

Right now this version of printsys.h is a bit polluted with code that
really belongs in some spooler specific header files but you can get
the idea of the API in general.

There are five basic concepts:
1) key value pair.
2) print system.
3) printer.
4) print job.
5) document.

The general process of printing a job is:

1 - open up the print system
2 - enumerate the printers
3 - select the appropriate printer (this gives you key value pairs
which are the attributes of the printer)
4 - create a print job with the appropriate attributes (number of
copies etc...)
5 - submit the various documents

The key improvements over what we have right now are:
1) There is an API for enumerating printers without having to write
your own printcap parsing routines.
   - One key feature of this which is really important is once we have
     all the applications and the spooler converted over to using this we
     no longer have to be dependant on printcap files. We can store
     the printer configuration information in NIS, LDAP or in a
     database or whatever.
   - Right now there are a huge number of printcap parsing routines
     floating around inside different applications. This would
     stanardize them all on one API and remove a lot of really ugly
     parsing code (primarily in the spooler and the associated print
     software). 
2) There is an API for querying the configuration of a printer.
3) There is an API for submitting document data, and document references.
4) There is a way to specify multiple documents data streams within a
job. 
   - Consider this for a moment. If  an application wants to print a
     one document print job you have two choices: 
     a) open a pipe and pass the data into the lpr command.
     b) write the data into a temporary file and call lpr with a
        command line argument.
     The advantage of proceedure "a" is that it is more efficient in
     both disk space and computer overhead because it doesn't require
     double storage of the document and once by the spooler. The
     application can simply stream the data into a pipe connected to
     the "lpr" command. 
     However, if an application wants to print a 2 or more document
     print job it still has two choices but both have severe
     disadvantages:
     a) write the data into multiple temporary files and then call lpr
        with the names of the files as command line arguments.
     b) iterate over all the data streams and make them independant
        print jobs rather than documents within a print job.
     c) concatenate all the documents into one large single document job.
     The disadvantages of proceedure "a" are the double storage of the
     file discussed above. The disadvantages of "b" is that the
     documents are no longer logically grouped into one job. This is
     due to the fact that the "lpr" command cannot accept multiple
     streams since it has only stdin. "c" looses the distinction
     between the seperate documents.
5) There is a method of passing both job and document
attributes. Right now there are very few attributes that can be
specified on the command line. We extended the "lpr" command to take a
"-o" option to specify job options. This is similar to the "-Z" option
in LPRng. However, the original "lpr" command does not accept these
either of these options and detecting if you can use "-o","-Z" or
nothing at all can be tricky. Most programs don't bother even trying.

-ben

> Hi all,
>  Could somebody tell me what method/technology are we going to use for
> printing in GNOME? I understand that PANGO may play a part in the
> rastering/rendering of the text which is all preprocessing of text
> before it reaches the printing stage. My question focuses specifically
> on what happens after this. Will we be just using lp/lpr? If so how? If
> not, what will we be using?
> 
> All answers to these questions greatly appreciated.
> 
> Thanks & Regards
> 
> Brendan.
> 
> _______________________________________________
> Gnome-print maillist  -  Gnome-print@helixcode.com
> http://lists.helixcode.com/mailman/listinfo/gnome-print