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

[Michael Sweet]

Johannes Meixner wrote:
> ...
> I suggest to add for each "speed" attribute a mandatory
> "quality" attribute which reperesents how good the printout
> looks for the respective sample (e.g. a very fast driver
> which produces fuzzy text output or wrong colors should
> get lower rating than a medium speed driver which produces
> good output quality).

Quality is entirely subjective, so I'd rather stick to values
that can be calculated the same for all devices.

#3 will reflect whether the driver supports all of the device
resolutions and qualities, and #4 through #6 only measure the
performance of the highest-quality modes.

> I suggest to add for each "speed" attribute an optional
> "cost" attribute which reperesents how much load it causes
> on a print server to produce the printer specific data.

Realistically, no current driver costs appreciably more than
another these days.  The biggest difference comes from the
driver type and the speed of the printer (the computer usually
waits on the printer...)

Regardless, the existing cupsFilter lines include relative cost
values for the driver's filters and could be used to compare two
drivers...

> I suggest to add for each attribute an optional "weight"
> to make it possible that some attributes have higher priority
> than others (e.g. the "weight" for the "quality" attributes
> might be 4 and for the "speed" attributes 2 and for the
> "cost" attributes the default 1 to that "quality" is
> heavier than "speed" and "cost" together).
> ...

That's not something that belongs in the PPD file, but in the
application that is interpreting the data.


>> cupsDriverAuthor (ppd-author text)
>> ----------------------------------
> ...
>> Examples:
>>
>>     *% HP PostScript printer driver without filters
>>     *cupsDriverAuthor: "HP"
>>
>>      *% ALPS printer driver using Foomatic
>>      *cupsDriverAuthor: "Masakazu Higaki"
>>
>>      *% Gutenprint printer driver
>>      *cupsDriverAuthor: "Gutenprint"
> 
> I sugest to allow translation strings so that a printer setup
> tool could provide more meaninfgful information to the user
> (instead of hiding them in PPD file comments) and use the
> main-keyword option-keyword/translation-string: "value"
> syntax for this like (lines wrapped only here in the mail):

No.  The driver type provides the type of driver, the author is
just to show who created the driver, not to provide a long
description.  The application you use to add a printer can
combine the different fields to give the necessary information
to the user if more than 1 driver is available.

The comments are just there to provide context for the examples,
not something you would actually include in the PPD file...

If you really want a long description, then we should have another
attribute (cupsDriverDescription) that can be localized.

> ...
> I suggest not to mix-up the different use-cases into one
> attribute but to keep them seperated and have seperated 
> attributes for the different use-cases so that a printer setup
> tool can focus on one particular use-case.

The problem with this is that you'll have no standardization,
making this whole rating system useless.  We also don't have so
many drivers that 20 use cases are necessary.  Some drivers
provide photo-quality printing and some don't.  Some drivers
can print graphics quickly, while others print text quickly.

The goal here is to suggest a driver that will print the fastest
for the user's primary type of printing while supporting the most
functionality of the printer.  Adding additional (and optional)
use cases will not help us do that.

> I suggest to provide translatable texts for each attribute
> in the PPD so that a printer setup tool can show meaningful
> info to the user in the user's own language.

No, these attributes are not for human consumption.

 > ...
> I think we don't have the knowledge to provide good values
> for this attribute because we don't have such perfect
> knowledge about device capabilities and driver capabilities.

Huh?  We are focusing on 3 basic use cases (text, graphics,
photos) which either are or are not supported by a driver/device
combo.  The numbers we provide are essentially unbiased - they
can be calculated the same by everyone and we will provide the
same test data to be used to do the calculations.

> Additionally this attribute seems to become terrible
> complicated for devices which can be extended e.g.
> by duplex units, additinal paper trays, ...

No, it won't.  The tests will be for simplex printing without
finishing, using the highest-quality monochrome (text speed) or
color (graphics and photo speed) modes supported by the driver.

A driver only supporting 600dpi photo printing may print photos
faster than a 1200dpi driver, but the driver rating will be
reduced for the 600dpi driver...

> For example a generic PCL5e driver would have to have
> high rating on a PCL5e device which cannot be extended
> but low rating on a PCL5e device which can be extended
> so that for the user it looks as if the extendable device
> is not well supported but how do we tell it to a user
> who uses (or wants to buy) the extendable device
> without all the extensions that the device is well supported
> by this driver if it is used without all the extensions?

That's a completely separate issue - all we care about in the
PPD file is how much support is provided.  The Linuxprinting/
openprinting database can provide the details if the user is
researching a printer to buy...

> On the other hand: How do we tell a user who uses (or wants
> to buy) the extendable device with all the extensions that
> the generic PCL5e driver does not support the extensions?

Presumably a driver targeted for that device will provide the
IEEE-1284 device ID or the make and model (otherwise it would
not be a close match), and the rating would be lower for the
driver that does not support all of the features/options.

> It seems it must be allowed to have an arbitrary number
> of keywords which represent how well the support is.

I don't think that is needed in the PPD files.  Even so,
most of that information is already available in the PPD file -
Duplex option, InputSlot option, etc...

If we added the cupsDriverDescription attribute, you could
include human-readable text explaining any driver limitations.

> ...
> It seems we are about to copy the OpenPrinting database
> and whatever other existing sources of information
> more or less completely into PPDs which I appreciate
> very much because I always thought that PPDs should
> be THE source of information regarding printer setup
> (which includes which model is how well supported).

It may be possible that this information can be copied or
calculated from the current database information, but that is
not the intent.

We DO NOT want to encode all of the driver database information
into the PPD files.  My only motivation here is to support
better possibilities for driver selection based on simple
criteria.

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