[Printing-architecture] Self-certification of Printers and Print Drivers for POSIX/Linux

[Till Kamppeter]

Marcelo Ricardo Leitner wrote:
> Hi all,
> 
> On Fri Jul 13, 2007 at 16:42:33 +0100, Till Kamppeter wrote:
>> My suggestions for the testing are the following:
>>
>> - Distributions must be LSB compliant. This way they have a common 
>> environment for binary executables. LSB 3.2 will require important 
>> interfaces for printing functionality in applications and for printer 
>> driver integration.
>>
>> The driver package should be made in distribution-indepent form to cover 
>> all Linux distros with one driver.
>>
>> - Core/system components which need to be tested:
>>
>>    o CUPS
>>    o Ghostscript
>>    o foomatic-rip
>>
>> The printer drivers interact only with these ones. Apps send jobs to 
>> CUPS/the printing system.
>>
>> - One good test would be to set up a print queue for the printer pointing 
>> into a file and to print into it. The output file must have a reasonable 
>> size after that. If something in the chain is missing this test would fail. 
>> If there is physical access to the printer, printing on the printer should 
>> also be tested.
> 
> I used this kind of test while developing the now old Conectiva Linux 10 and
> it worked pretty well. I had scripts that could even grab the relevant
> error from cups' error_log (debug level) and identify it. Then after running
> this test for all printer/driver combinations (that time from
> foomatic-configure -O), I had a clear view of the main problems in the
> distro. This is a nice test (distro level?), indeed.
> 

Great. Can you make the code available? We would have to update it a 
little bit, for example using "lpinfo -m" instead of "foomatic-configure 
-O" (and recursively searching /usr/share/ppd on non-CUPS systems). We 
can make test queues also on non-CUPS systems with foomatic-configure 
and on unknown printing systems (or for pure driver consistency testing) 
we can use pure spooler-less direct calls of foomatic-rip (with the 
"--ppd" argument).

> But, unfortunately, this won't work with drivers that requires direct access
> to the device.
> 

Yes. Most printer drivers are filter style (PostScript to printer's 
language by a combo of Ghostscript and the driver). If direct printer 
access is needed the PostScript-to-printer's-language filter is often 
separate from the low-level driver module (like in HPLIP). Without 
printer we can only do the filter test, unfortunately. But often filter 
and low-level driver come in the same package, so the presence of the 
filter would imply the presence of the low-level driver.

>> - The user tool should be a distribution-independent package (or a package 
>> each distro has to supply) which runs the tests in an automated way and 
>> presents the results in both machine- and human-readable form. It should 
>> also provide info to the user what he will need to do to make his printing 
>> working.
> 
> I can't see what this application would do. The main reasons I see for it
> not working are either he made a custom installation (and thus he has some
> linux development skills) or the distro didn't do its job well, assuming the
> driver was well tested by the manufacturer and it really should work with
> the printer being used.
> 
> Can you explain a bit more about this tool please?
> 

The user tools would be the complete test suite, consisting of all test 
script. So the user can test whether his distro has a consistent 
printing system (CUPS, Ghostscript, foomatic-rip, Ghostscript having 
"cups", "ijs", "opvp", "pxlmono", and "pxlcolor" output devices, for all 
installed PPDs the appropriate driver is present, ...), a driver shipped 
by the manufacturer of a printer is working (test should be possible 
without the printer, so download manufacturer driver -> test -> buy 
printer).

    Till