[cups.general] RFC: New Driver Rating/Information Attributes

Michael Sweet mike at easysw.com
Sat Jan 27 08:09:24 PST 2007


Till Kamppeter wrote:
> I think I will add these data items to te OpenPrinting database so hat 
> the get into generated PPDs.
> 
> I suggest to add the following items, too:
> 
> *cupsManufacturerDriver: True
> 
> The driver author entry does not necessarily show in a machine-readable 
> form whether the driver is from the printer's manufacturer or not. With 
> this flag manufacturer-supplied drivers can get clearly marked.

cupsDriverAuthor == Manufacturer means that the driver is from the
manufacturer...

> *cupsDriverLicense: "GPL"
> *cupsDriverIsFreeSoftware: True
> 
> This can help the distro's printer setup tool to tak into account 
> non-free drivers or not, especially when we have ditribution-independent 
> driver packages whic the setup tool can automatically download.

Wouldn't a single "cupsDriverLicense" be sufficient, with "EULA" or
some other predefined license string indicating non-free software?

> * cupsDriverSupport: "..."
> * cupsDriverDescription: "..."
> 
> Human-readable fields, the former is for support contacts, like mailing 
> lists, manufacturer-supplied support, ... The latter is a general 
> description of the driver, especially telling about driver properties 
> which cannot be represented by the other suggested keywords. These two 
> should be provided with translations.

Um, we already have some of this - look at the current CUPS PPD spec for
the attributes used by Apple for this.

> * cupsDriverIsInstalled: "..."
> 
> A shell command line which exits with 0 if the driver is locally 
> installed or with 1 otherwise. So the user can get presented only the 
> installed drivers by the printer setup tool.

I don't think this is needed; if this becomes a problem, we can just
check against the cupsFilter lines (the scheduler already does this
for printers that are added...)

> Obtaining all this information for a new printer/driver could be made 
> part of the OpenPrinting printer certification program. Certification 
> could be also marked by a keyword:
> 
> *cupsDriverOPCertification: None
> *cupsDriverOPCertification: PrinterManufacturer
> *cupsDriverOPCertification: DriverAuthor
> *cupsDriverOPCertification: OSDistribution
> *cupsDriverOPCertification: CertificationAuthority

As I said before, I'd rather not have the PPD file contain all of
the driver database information.

> Another thing is whether we should start the keywords with "*cups...", 
> as this information serves as well for other printing systems, like 
> Solaris LP. Perhaps we better use "*OpenPrinting...".

Anything that is provided by CUPS should have a "cups" prefix.  These
attributes can be provided by the CUPS_GET_PPDS operation.

If you will be embedding information from the OpenPrinting database
that is not part of the CUPS standard attributes, then those (and only
those) should use an "OpenPrinting" prefix.

> ...
> Perhaps we better call it
> 
> *cupsDriverSupplier: "Gutenprint"

I used "author" since "supplier" is not sufficiently unique for things
like Ghostscript drivers supported through Foomatic.

> and use always manufacturer or project names, the same as we use for the 
> PPD directories in the new FHS extension 
> (/usr/share/ppd/<supplier>/...). Many drivers, like GutenPrint have very 
> many persons who worked on them.

True, but in those cases the drivers come from the developers as a team.
Other drivers are developed by individuals and not maintained by a
project (such as most of the drivers in Ghostscript).

>> cupsDriverType (ppd-type keyword)
>> ---------------------------------
>>
>>      *cupsDriverType: "driver-type"
>>
>> This string attribute defines the type of driver, currently one of
>> the following:
>>
>>      - PostScript; a driver that sends PostScript to the device - this
>>        is the default for PPD files without cupsFilter attributes
>>      - CUPS-Raster; a driver that converts CUPS raster data to the
>>        device's native format - this is the default for PPD files
>>        listing an application/vnd.cups-raster filter
>>      - Foomatic; a driver that uses the foomatic-rip wrapper script,
>>        possibly using a Ghostscript driver, to convert to the device's
>>        native format
>>      - OPVP; a driver that uses the Open Printing Vector Protocol to
>>        send print data to the device
>>      - Unknown; a driver that uses some other filter technology - this
>>        is the default if the driver is not PostScript or CUPS-Raster
>>
> 
> OPVP does not fit very well here, as it does not have a standard CUPS 
> filter. OPVP is only a communication method between GhostScript and the 
> driver. It does not provide anything for GhostScript to be called by 
> CUPS. I have already seen sample drivers using foomatic-rip but also 
> other drivers which use a simple, custom-made "psto..." or "pdfto..." 
> CUPS filter. And if we have OPVP listed we would also have to list IJS.
 > ...

The purpose was to list the standard LSB driver types.  OPVP can (and
probably will, if it ever gains enough support) run independent of
Ghostscript and Foomatic.  IJS is always used through Foomatic, so it
inherits all of the Foomatic constraints/behaviors...

To reiterate a point: the ONLY purpose of my proposal is to add CUPS
support for "intelligent" driver selection based on driver type,
rating, and performance for the type of printing the user specifies.
I have no desire to add all of the information of one particular
driver database to the data supported by CUPS, as it does not help
us engineer a proper replacement for the static "recommended" strings.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com




More information about the cups mailing list