HELP WANTED: kdeprint with GNUlpr

[James Richard Tyrer]

Goffioul Michael wrote:
> IMHO, what's really missing in LPRng to build a decent support
> in KDEPrint is an API and a library. Any command/operation has
> to be made by executing a program and parsing its output, so this
> heavily relies on a specific syntax. 

The current method (in kdelibs/kdeprint/lpr/lpqhelper.cpp) relies on a fixed format output 
line.  This doesn't appear to be the same in different versions of: 'lpq'. :-(

A simple solution to this is to have yet another command line option for 'lpq' to cause it 
to produce only the output needed and that output as a tagged list.

> This is a pain from the
> client programmer point of view. That's why CUPS support is much
> more developed in KDEPrint: it provides a full API.
> Another problem with LPRng is the *wide* variety of driver
> systems existing out there, each one using its own files, setup,
> DB syntax or whatever. Again here, CUPS is more easy to use:
> you can request the server for the driver file, and it's always
> a PPD file. 

Actually, those are not PPD files.  They (PPDs for CUPS or FooMatic, and non-PostScript 
Printers) are special CUPS modified PPD files.  They contain a line that tells it which 
driver to use and additional resolution information.  So what is really happening is that 
it appears to be simple, but it isn't.  With FooMatic, you go back to using a specific 
driver setup for the foomatic-rip but you still need to have a modified PPD file for CUPS 
to tell it to use that driver and have the resolution information.

So, if you are going to use REAL PPD files with non-PostScript printers, you are going to 
need to also have a configuration file which contains the PPD file name, the driver setup 
to use with it and the GhostScript resolution parameters available for each resolution in 
the PPD file.

> Presenting print options is then quite easy.

Using any data based system is always simple if the data for your printer is in the 
system. Any such system comes down to needing the correct 'magic file' and if you don't 
have the correct 'magic file' then you are dead. Systems should be judged by how easy it 
is if the data for your printer isn't in the system.

> LPRng is probably a wonderful print spooler for the command-line,
> but it's really difficult to build a modern GUI on top of it.
> The first thing I would expect from LPRng is an API.

I joined the mailing list so I guess that I will give them a hard time too.  I guess that 
you understand that Engineers are trained to find what is wrong with things and how to fix 
it -- and secondarily to do so without emotion.  A quite useful talent, but we can be 
somewhat irritating at times. :-(

--
JRT