HELP WANTED: kdeprint with GNUlpr

[James Richard Tyrer]

Goffioul Michael wrote:
>>> 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?
> 
That would be a better solution.  So, that is #3 on the to do list.

#1 is finding the bug in KJobViewer.  I had if working for a few minutes so it can't be a
large problem.

#2 is getting the default paper size as you suggested else where.
> 
>> 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.

I don't think that this is necessary since it is first to describe the printer and second
to provide information for the *application's* PostScript 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 one I made for my old Epson LQ1000 serves its purpose in WINE and Open Office.
> 
>> 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, most applications and printer control widgets assume 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?
> 
The *filter* would still need a configuration file to associate a printer driver with the 
printer's PPD file.
> 
>>> 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? 

It works fine with the GNUlpr filter.  I contacted the LPRng mailing list.

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.

What I am suggesting that instead of being put in the PPD file that all GS Device (or 
other driver) information should be in a separate configuration file (like: "LibAPS":

	http://sourceforge.net/projects/libaps/

Yet Another Dead Printing Project. :-D
).

I would suggest that the configure file contain:

<User assigned printer name>
     <PPD name with full path>
     "GhostScript" <device> | <Other device> | "PostScript"
     <resolution(s)> | "ALL"
	<Command line> | <other filter information>
	<other dependencies> | ""
             Capabilities supported

Which I think is all of the information that could possibly be needed for the print driver 
and printer control program.

My take on this is that this should be a site specific configuration file with entires 
only for what you are using rather than a 5K + exhaustive file.  This could be generated 
in various ways with a configuration program.

--
JRT