[Printing-summit] [lsb-discuss] Printer/driver testing
till.kamppeter at gmail.com
Tue Aug 22 08:27:15 PDT 2006
Johannes Meixner wrote:
> 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
> 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?
For the hardware infrastructures one has still to make different
packages, one for i386, x86_64, ppc, ..., but this is already much less
then for each combination of distribution and processor.
> 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"?
The packages will work with all distros compliant to a given LSB
version. The LSB standard assures which libraries, directories, and
other software is available.
> 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
> 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".
Such a package must be developed to work on LSB-compliant
distributions., as ISVs develop application software which runs on
LSB-compliant operating systems.
> 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?
Nothing should be overwritten, also it is not a good idea to have
different foomatic-rip versions on the same system. My suggestion is to
add foomatic-rip as a requirement of LSB 3.2, as every distribution
> 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.
Only for availability testing of drivers one PPD per driver would
suffice, but we want once to test the PPDs themselves and we also want
to test the consistence of the distribution, checking whether for all
shipped PPDs and Foomatic data also the appropriate drivers are shipped
in a working state.
> 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).
Having standard option names would be a good idea. Then an automatic
test only needs to look for these and go through their choices.
More information about the Printing-summit