HELP WANTED: kdeprint with GNUlpr

[James Richard Tyrer]

Goffioul Michael wrote:
>>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.
> 
No, the '-Z' options are available with the new version.
> 
>>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 exception to that is the resolution.  The "printerdb" file is supposed to list the 
available resolutions.

> The easiest is to
> present all options, unsupported ones will simply be ignored
> by the driver. 

And, again, the only problem here is the resolution since if the wrong resolution is 
passed to GhostScript, it will not be ignored.

> This is not good from a GUI point of view,
> but better than nothing.
> 
Yes, the best thing from the GUI point of view is to have a PPD file.  Then you need a KDE 
version of PPD-O-Matic to make PPD files. :-)
> 
>>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.
> 
> 
> 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, 

If you download some PPDs from linuxprinting.org, you will see that they contain 
considerably more than just one line.  This is probably all FooMatic stuff, but you have 
to use FooMatic with CUPS unless you buy the proprietary drivers.

The main issue is the resolutions listings.  This is odd, because a PPD file can have 
non-square resolution, IIRC -- I will have to check the spec.

> but I think that the manufacturer only
> provides you with a PPD file if it *is* a PS printer.

They should start doing so.  But, these would just be pure PPD files -not CUPS or FooMatic.
> 
> 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.

Easy to use if the 'magic file' exists.  They don't have a PPD for my old Epson LQ1000.

--
JRT