HELP WANTED: kdeprint with GNUlpr

[Goffioul Michael]

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

I meant that the option set is fixed, not their values. But I find
it rigid to have the same options for all HP printers (from the
low-end deskjet, to the high-end laserjet).

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

You're right about the resolution, the problem is that you have
to look for available resolutions in the whole printerdb file
(or cache them somewhere). But this is only adaptating how
LPRngTool is handled in the lpr plugin. As the guy in charge
of the LPR plugin (:-)), maybe you could have a look at it. This
means to load available resolutions from printerdb or some cache,
and mix this with the static option set loaded from lprngtooldriver1.
All the code is located in kdelibs/kdeprint/lpr/lprngtoolhandler.cpp.
What do you think?

> 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 PPD files generated by Foomatic are to be used with the
Foomatic driver, nevertheless they are still fully Adobe
compliant. But let me stress on this: for non-PS printers, a
PPD file is bound to the driver. This is always the case, except
for PS printers. Even if Foomatic added a lot of keywords, this
is still parsable in a standard way, and a client can still show
options as for manufacturer-provided PPD files. There's no
change.
A PPD file without the associated driver is useless.

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

Because printers can have non-square resolution.

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

Hence useless (except for PS printers): how would the spooler
know how to convert from PS to the language supported by the
printer? what is the driver?

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

Did you try to contact linuxprinting.org guys to update the DB?
Did you try with a generic driver?
I don't really understand the point of having a magic file. You
also need to keep it updated, like the Foomatic DB. The problem
is the same. But maybe I misunderstood you.

Michael.