HELP WANTED: kdeprint with GNUlpr

[James Richard Tyrer]

Goffioul Michael wrote:
>> 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?

Current output from 'lpq' fixed format:

lp is ready and printing
Rank   Owner      Job  Files                                 Total Size
active jrt        5     ...                                  73269 bytes
1st    jrt        6     ...                                  73269 bytes

Suggestion:

Message=lp is ready and printing;
Rank=active:Owner=jrt:Job=5:Files=...:Total Size=73269 bytes;
Rank=1st:Owner=jrt:Job=6:Files=...:Total Size=73269 bytes;

This should be easier to parse.

> 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
> 
Yes a library call would be better.
> 
>> 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).
> 
I have to differ with you here.  A "real" PPD file has only two type of content:

1.	The physical capabilities of the printer.
2.	How the *application* (the PS driver) should use these.

This information is for the application producing the PostScript data file to use.

I have this take on it because I started using PPD files because *applications* needed
them (WINE & OpenOffice).  Therefore, I made a PPD for my old Epson LQ1000 by editing the
generic OO PPD file.  In any case, the paper sizes available, printable area on them and
resolutions are not dependent on the GhostScript Device.

The FooMatic PPD files contain in addition to this, information for the filter to use when 
executing GhostScript.  This information is not used by the application so it does not 
need to be in a PPD file.
> 
>> 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... 

Well I appear to have failed at doing this.

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

The reason is that putting this all in a poorly documented 'magic file' makes it hard to 
add a printer which GhostScript supports but the filter system doesn't.

In my case, the printer is supported and I know (or can figure out) the command line to 
use it with GhostScript.  But, I don't know how to edit the 'magic file'.

--
JRT