HELP WANTED: kdeprint with GNUlpr

[Goffioul Michael]

> Well, sort of.  What the gpr program does is put a widget 
> between the application and lpr, 
> much like KDEPrint does.  The application calls 'gpr' instead 
> of 'lpr' and up pops a 
> widget where you can set the options which are turned into a 
> command line.

...which is exactly what kprinter does. The problem is to
present the user with the correct set options, from the
driver associated with the selected printer. This is fairly
easy for a PPD-based print system like CUPS, much more
complicated for LPRng (where you can have Foomatic/PPD,
APSFilter, printtool, LPRngTool...)

> Note that the IFHP filter for LPRng also uses the same '-Z' 
> options (IIUC).  With this 
> quite elaborate filter system, the dependence on the actual 
> driver is eliminated and 
> replaced with a uniform interface.  The: "ihfs.conf" file has 
> the same function as a data 
> base.

IIRC and IMHO, the drawback is that you have a single print
option set with some of them enabled/disabled according to
to the printer. This is too rigid for modern printers.

> This could be fixed with KDE Print if it used a PPD file 
> rather than the exhaustive list 
> of options in the: "lprngtooldriver1: file.  You would still 
> wind up with what CUPS is 
> missing: a configuration file that lists the PPD file name to 
> print driver association. 

This could be better if LPRngTool or more generally LPRng
used PPD file to describe print queues... I don't consider
that it is the responsability of KDEPrint to provide PPD
files, this is a driver issue. LPRngTool uses a fixed option
set, so you only need a single description file, which is
the role of lprngtooldriver1 (I could have translated it to
a PPD file, but I don't see any reason, this simple syntax
is easier and faster to parse).
At client side, LPRngTool even doesn't provide you any way to
know if an option is supported or not. The easiest is to
present all options, unsupported ones will simply be ignored
by the driver. This is not good from a GUI point of view,
but better than nothing.

> This is needed because CUPS doesn't really use a PPD file; it 
> uses a modified PPD file. 
> If you use just a plain PPD file, it doesn't work.  FooMatic 

No, because a PPD file is primarily describing a PS printer,
and most printers out there are not PS. in the UNIX world,
this is work around by using gs and faking PS printers. PPD
files are then related to the gs driver that is used as
"PS->data translator". But in any case, you need to tell
the spooler which convertor it has to use: in CUPS this is
stored in the PPD file. You can use plain PPD files only
with PS printers, but I think that the manufacturer only
provides you with a PPD file if it *is* a PS printer.

What Foomatic has done is to build a generic PS->any convertor
(based on gs and some additional printer utilities), using a
database making the relation between a printer, an option set
and a gs driver. The whole stuff is PPD-based, which make it
easy to use it in clients.

Michael.