[Printing-summit] [lsb-discuss] Printer/driver testing
till.kamppeter at gmail.com
Tue Aug 22 10:09:14 PDT 2006
Stark, Jens wrote:
> Till wrote:
>>Having standard option names would be a good idea. Then an automatic
>>test only needs to look for these and go through their choices.
> Correct in principle. However, a lot of PPDs is developed without
> Linux/CUPS in mind, then used for it. As long as Adobe does not decree
> option names, I see little chance of this happening. Also, what happens
> with "stuff not mentioned by the standard" ? Old PPDs ?
> I would most likely start with cupstestppd, maybe extend it to test
> PPDs. The permutation of ALL options in one PPD would create a lot of
> print jobs. Would you want to test them all ?
> With what would you want to test them ? Print test jobs ? Some of the
> options, like RAM size, do not really change the output.
> As an example: An assumed machine might have four normal paper trays,
> one bypass tray and a LCT (large capacity external tray). It can print
> in 300, 600 and 1200 DPI. It can staple in two different positions,
> using one or two staples. Under certain circumstances, it can also
> staple for brochures. The device prints simplex and duplex (book or
> calendar). Plus it comes with a postbox finisher with 20 bins, can print
> black/white or color, optimise for quality or speed. (Yes, it possibly
> has far more options, but let's just talk about these so far...)
> This gives you : 6 (trays) * 3 (resolution) * 3 (staple positions)* 3
> (sides) * 20 (finisher bins) * 2 (color) * 2 (quality) = 12960 possible
> Nobody will want to test this.
> What COULD be done is providing an original, both as (ps?) source and
> PDF, maybe as sample prints, and ask the tester to provide the settings
> recommended for this use case.
> (You want photos on plain paper ? Set this to "high" and that to "photo"
> and the little thingie over there to "plain paper". Business graphics ?
> The same, but set the second one to "line graphics".)
> Difficult - also difficult to find use cases for things that only a few
> systems can do. (Inserter units and finishers come to mind.)
So perhaps testing should be done in one of the following two modes:
1. Printer hardware testing
The actual printer is present. Then there is usually also someone who
connects it to a computer or a network. This person can determine which
type of printer it is and then select appropriate use cases from the
ones available in the standard testing procedure. He selects one or more
option sets suitable for the test items given in the selected use cases,
prints and evaluates and rates the results. He fills in the report form
with all the choices and settings and results.
2. Software-only driver testing
There is a Linux distribution or other driver collection but naturally
not all the printers which are supported by this software package. The
goal of this test type is the consistence of the software package. As
here 100 or 1000 jobs have to be executed an automated procedure is
recommended. Here it would be already helpful to run one or very few
(with variation in options with an Adobe-defined standard name) jobs to
determine that the driver is there and does not simply crash and that
the principal invocation of the driver in the PPD file is correct.
Finding all PPDs (including PPDs dynamically generated by CUPS 1.2.x)
works with "lpinfo -m" on CUPS systems.
More information about the Printing-summit