HELP WANTED: kdeprint with GNUlpr

[Goffioul Michael]

> 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.

XML?
I'd prefer of course an API for 2 reasons:
1) I'm sure LPRng already uses defined structure to store data like
   print queues and jobs internally, it's "just a matter" of putting
   it into a library, adding top-level headers, and link tools like
   lpq, lpr to that library
2) it's much faster

> 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.

There's some paradox here. You cannot use a REAL PPD file with a
non-PS printer. A REAL PPD file relates to a PS printer. But we
still use PPD files for non-PS printer by using ghostscript
pre-filtering. So the PPD files much describes the capabilities
of the gs driver than the printer itself. In that context, you
cannot dissociate a PPD file (for a non-PS printer) from the gs
driver. To use such a PPD file, you NEED to know the gs driver,
so why not store it inside it.
OTOH, REAL PPD files are only for PS printers and provided by
manufacturers. Where would you find PPD files for non-PS printers?
To my knowledge, there's only Foomatic (or gimp-print, but it's
integrated into Foomatic).

> 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.

Of course, the DB probably misses entries for the very latest
non-PS printer by HP. But then, you can still add entries in your
DB for generic printers like: PS, PCL3, PCL5, PCL6...
Anyway, drivers are based on gs. If a printer is really not
supported (even using generic drivers), then it's not supported
at all, and you have to wait for someone to write the gs driver
for it. Then, you may think of having PPD files for it, but it
is still bound to the driver itself.

In my understanding, there's no point in splitting the PPD file
and the associated gs driver in the case of a non-PS printer.

Michael.