[cups.general] Why not "recommend" PPDs in the NickName?

[Michael Sweet]

Till Kamppeter wrote:
> ...
>> Right, and that does *not* require the word "recommended" in the
>> NickName, which (without proper context) is useless and misleading.
>>
> 
> I can add one or more "*Foomatic..." keywords for drier type and 
> recommendation info. WDYT?

I would prefer a driver-neutral naming convention, so that we can
apply this to ALL drivers advertised through CUPS, and then we can
include the data as attributes returned by the CUPS_GET_PPDS operation.

What kind of information do you want to track?

My own list includes the general level of feature support (a percentage
roughly corresponding to your "supported fully" vs. "supported
partially" status) along with an indication for the type of printing the
driver is optimized for (either a bitfield or percentage for text,
business graphics, and photos.) and the type of driver (PS, CUPS, Foomatic)

Then when the user adds a particular printer and there are multiple
drivers available, we can ask the user (if we haven't already) what kind
of printing they will be doing and then narrow the list of drivers
presented to the user.  Ideally this "interview" process would reduce
the list of drivers to 1, yielding a recommendation for that user.  At
the very least we'll have a short list with the best match at the top.

> ...
> I do not list or want to list non-working drivers, I list all drivers 
> which somehow work. If a new better driver appears I mark it 
> recommended, so that users know which driver works best.

"Which driver works best" usually depends on what you are trying to
do... :(

> ...
> The CUPS-internal page accounting works with foomatic-rip, I have only 
> discovered now that at Ubuntu they have disabled it.

That might explain all of the user complaints in the CUPS forums... :)

> What do you mean with Windows clients? Clients which use a PostScript 
> driver for Windows and the PPD of the CUPS queue? Or a special CUPS for 
> Windows software? What exactly does not work with a foomatic-rip-driven 
> queue when a job comes from a Windows client?

Since Foomatic options are not passed in PostScript setpagedevice
commands, foomatic-rip will never see the option selections from the
Windows client - they aren't passed in IPP attributes/options like they
are from CUPS clients.  I know I've mentioned this to you before on
several occasions...

The result is that users will call/email/post that their Windows clients
are printing with the wrong size/options/etc.  Normally I find that
they are using a Foomatic driver (usually unnecessarily) and have to
explain the issue.

One thing you could do is just change the Foomatic options to use the
JCLSetup section and set the JCLBegin and JCLToPostScriptInterpreter
strings like we do in cupsAdminCreateWindowsPPD().  This will allow
the Windows driver to pass the options using the cupsJobTicket
comments, and foomatic-rip will get the options just like with CUPS
clients.

> Manufacturer-supplied PPDs for PostScript printers I usually always 
> recommend, and if they are on OpenPrinting, you get them when 
> downloading the recommended PPD file. But even here is an exception: The 
> HP LaserJet 1320 is a PostScript printer with rather weak hardware power 
> and users complain about that it is not performing well with PostScript 
> and recommend using it with a PCL driver, like HPIJS. Due to such 
> exceptions the OpenPrinting database should give hints to the users.

Perhaps a "speed" value (pages per minute) can be provided for different
use cases (text, business graphics, photo printing), with "0" meaning
that use case is not supported by the driver?

> CUPS raster drivers integrate much better with CUPS, but one cannot 
> recommend them in all cases, as for example for recent HP PhotoSmart 
> printers. The CUPS raster driver which makes these printers work is 
> Gutenprint (model selection HP DeskJet 990), but Gutenprint does not 
> support advanced features like borderless or duplex, whereas HP's HPIJS, 
> which unfortunately is not a CUPS raster driver, supports these features 
> (in Atlanta HP guys promised to also make a CUPS raster driver of HPIJS, 
> but it never appeared up to now).

I've provided the code for it and the CUPS command filter (for cleaning
print heads, etc.), hopefully it will be available soon...

> Probably ratings like there are currently for the printers ("Perfectly" 
> ... "Paperweight") should be assigned to the printer/driver combos and 
> as the preferred driver the one with the highest rating should appear. 

A percentage (100 means all printer features are supported, 0 means the
printer is not supported at all) would provide more "resolution" for the
rating and could be calculated the same way for all devices.

Thus, the HPIJS drivers might only get a 95% rating if they don't
support all resolutions of a device, but they'd still (likely) be the
best choice.

> The ratings could even be done separately for text, drawings, and 
> photos, and the setup tool could create more than one queue if there are 
> different best drivers for the different tasks.

I'd recommend against creating multiple queues automatically - let the
user do that if they want...

> In addition the drivers should get some extra fields, like "from 
> manufacturer", "free/non-free", "IJS/CUPS/OPVP/other" ...

An author field...

> This will give much more information to the user, but it makes also 
> things more complicated, especially several thousands of printer/driver 
> combos need to be rated.
> 
> One step which I have already done to reduce the number of drivers is 
> that I have marked drivers as obsolete if they get eplaced completely by 
> other drivers.

Good.

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