[Printing-summit] [lsb-discuss] Printer/driver testing andcertification

Johannes Meixner jsmeix at suse.de
Tue Aug 22 06:36:20 PDT 2006


Hello,

On Aug 21 16:00 Till Kamppeter wrote (shortened):
> linuxprinting.org should then provide distro-independent binary LSB
> packages of all free drivers AND the PPDs, so that PPD and driver can be
> downloaded.

Could you explain how "distro-independent binary packages" can work?

I expect unsolvable problems with various hardware architectures.
Or is it limited to Intel i386 compatible 32-bit binaries?

What about dependent software requirements (e.g. a particular
driver binary requires a particular version of a library).
How can this be checked with "distro-independent binary packages"?

Perhaps it helps a lot to define more exactly what "driver" means.
If "driver" only means a program which converts a data format
which can be produced by Ghostscript into a data format which the
printer understands, it should be no big problem to make the sources
of the driver so that there are only very generic dependent software
requirements.

But if a "driver-package" includes whatever nice tools
(e.g. a setup tool and perhaps even a graphical user interface),
it may become very complicated to make a "distro-independent
binary package".

The HPLIP software is a good example what I mean:

/usr/bin/hpijs is the plain driver but the HPLIP "driver-package"
includes very much other stuff and there is the problem how
to deal with such driver-packages.
Is it sufficient when only /usr/bin/hpijs works correctly
or what about the hp/hpfax backends, the scanner driver,
the graphical fax utility, the printer maintenance tool,
and the hp-setup tool?
All those additional stuff is expected to work by a normal user
if his all-in-one device is listed as "supported by HPLIP".

The HPLIP driver-package-sources contain foomatic-rip.
What should a "distro-independent binary package" do?
Should it simply overwrite an already installed foomatic-rip
(of course this is totally forbidden ;-)
or should it install its foomatic-rip into a special place
and point to this one in its PPDs (get one more foomatic-rip
with each driver package - support engineers will love it ;-)
or could it test whether foomatic-rip is already installed?


> In the tests of distros a script like Johannes Meixner has presented
> here should check whether the distro contains the basic set of drivers
> and PPDs and whether for each PPD there is the appropriate driver present.
>
> In the test of printers it should be checked whether the driver is
> available on the distros and/or on linuxprinting.org and certain use
> cases should be tested. Within a use case test one or more test
> documents should be tested with certain typical sets of option settings
> and every result rated with a level from 1-4 as suggested by Robert Krawitz.

To check whether a driver is available:
Shouldn't it be sufficient to have only some special PPDs
(one generic PPD for each driver) in the test suite
and a script which tests only those PPDs?
If the driver is not available or if it is installed at a wrong
place or wrong compiled so that it crashes, the test would fail.

To check whether a driver supports certain use cases:
Shouldn't it also be sufficient to have special PPDs
(for each driver one PPD with appropriate special default
settings for each use case) in the test suite and a script
which tests only those PPDs?

Checking the PPDs which are provided by a particular distro
seems to be much more complicated because there is no automated
way to use an arbitrary PPD with different use cases because the
option names in the PPD can be more or less random.

Therefore it may make sense to have a standard for option names
("main keywords") and choices names ("option keywords") which
are common for nowadays use cases but not yet described in the
PPD specification (e.g. for photo modes).
I.e. first of all standard use cases would have to be defined.
The existing "PrintoutMode" keywords are a good point to start
regarding standard option names and standard use cases.
Standard option names and standard use cases are user friendly
and they allow automated PPD checks whether or not a PPD
is in compliance to those standard and they can show the user
for which standard use cases a printer is supposed to work.

But there may be problems:
What if a weak printer provides for example the choices
- Photo.PlainPaper
- Photo.PhotoPaper
but a better printer provides only
- Photo
because it autodetects the media type?
For an unexperienced user the first one may look better
because it can print photos even on plain paper.
Therefore I think that the standard use cases should be kept
simple - e.g. only one "photo" use case which means to print
a photo in photo quality (i.e. for the first printer above
only Photo.PhotoPaper).


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