[Desktop_printing] Usability: Printing roles, tasks and environments

Johannes Meixner jsmeix at suse.de
Thu Mar 9 02:07:57 PST 2006


On Mar 8 13:12 Henrique de Moraes Holschuh wrote (shortened):
> On Wed, 08 Mar 2006, Till Kamppeter wrote:
> > In the PPD files the entries "Manufacturer" and "Product" should
> > correspond to manufacturer ("MFG:") and model ("MDL:") in the IEEE-1284
> > device ID string. More items of the device ID string can be in the
> > "1284DeviceID" entry of the PPD file.

I assume you meant "Manufacturer" and "ModelName" because
"Product" is for the PostScript Interpreter.

It depends what exactly "correspond" means.

I think the PPD files the entries "Manufacturer" and "ModelName"
have to be human readable strings which are what can be read
on the label on the printer, for example
"Everything Maker" "Fun-Printer XXL+ ColorMagic 2400DN"
or human readable strings which describe a series of printers like
"Everything Maker" "Fun-Printer ColorMagic+ series"

If the IEEE-1284 strings "correspond" to the human readable strings,
there is no need for additional "1284DeviceID" entries but
only "1284DeviceID" entries are really failsafe.

Otherwise at least one "1284DeviceID" entry is required, e.g.:
*Manufacturer: "Everything Maker"
*ModelName: "Fun-Printer ColorMagic+ series"
*1284DeviceID: "MFG:ACME;Model:acme funprinter+ colormagic 1200"  
*1284DeviceID: "MFG:ACME;Model:acme funprinter+ colormagic 1200D"
*1284DeviceID: "MFG:ACME;Model:Fun-Printer XXL+ ColorMagic 2400"
*1284DeviceID: "MFG:ACME;Model:Fun-Printer XXL+ ColorMagic 2400D"
*1284DeviceID: "MFG:ACME;Model:Fun-Printer XXL+ ColorMagic 2400N"
*1284DeviceID: "MFG:ACME;Model:Fun-Printer XXL+ ColorMagic 2400DN"

Alternatively multiple PPDs can be used but then some ModelName
entries look bad and may appear at a unexpected place in a sorted
list of model names if the exact IEEE-1284 strings are used.

The meaning of "correspond" could for example be defined as follows:
The strings A and B correspond when both strings are lowercased
and space characters and hyphen-like characters are removed
and then the resulting "unified" strings are the same.
"Fun-Printer XXL+ ColorMagic 2400DN" -> "funprinterxxl+colormagic2400dn"

For example the YaST printer config uses such kind of "correspond"
to find matching PPDs for an autodetected printer model (and some
more magic - e.g. "HP" and "Hewlett-Packard" also "correspond"
and a leading manufacturer name in the ModelName is removed)
but of course it cannot work correctly in any case.

And have the hopeless case in mind how many Epson USB printers
show up at the USB: As "Epson" "USB printer".

> You'd need a mapping table of some sort, preferably a regexp-enabled one
> with fuzzy capabilities if you want to be really generic.

Be very cautious which regexp you use to avoid to become too generic.

Otherwise it may happen that the config tool finds wrong PPDs
and this results a worst-case for any user who wants to set up
a printer when he can select a PPD which actually doesn't work
or even worse than worst-case ;-) when such a PPD is autoselected
and a queue is autoconfigured by a too-smart tool.

For example the characters '+', 'L', 'M' or the string 'PS'
often makes a big difference because they often indicate the
printer language, for example:
- only the '+' model supports PCL, otherwise it is "GDI"
- 'L' indicates the "GDI" model, without 'L' it supports PCL
- 'PS' or 'M' indicate the PostScript model, otherwise only PCL

> It also needs to do fuzzy-matching to find the correct PPD

In most cases there is no "the correct PPD" but several
matching PPDs.
The better the printer is regarding Linux support, the more
matching PPDs exists, in particular for the best color printers
which support PostScript, PCLXL, PCL5e, color PCL, ...
and there os no such "one best PPD" - in particular not for
the best printers regarding Linux support.

> IMHO the failsafe way to go about it is to add printer setup helper plugins
> that allow a driver to extend CUPS' capabilities of printer detection, PPD
> selection, and printer capability detection.  Anything else is just wishful
> thinking, IMHO.

I fully agree regarding the last sentence.

But I wonder how such a plugin could work.
CUPS' printer detection is done by running all backends.
Therefore all existing printer-specific detection plugins would have
to be simultaneously plugged in into all those CUPS backends which
match to a particular printer's connections (e.g. for a higher-level
HP all-in-one device: parallel, usb, hp, lpd, ipp, socket).

Kind Regards
Johannes Meixner
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/

More information about the Printing-summit mailing list