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

[Till Kamppeter]

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.

- 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.

    Till

Ira McDonald wrote:
> Hi,
> 
> The purpose of this note is to kick off discussion on this topic and to
> collect issues and details from all interested parties.
> 
> Background - there was a "lively" discussion during the Open Printing
> sessions of the recent Linux Foundation Summit about certification
> of printers and print drivers for Linux.
> 
> More than ten hardware and software vendors agreed unanimously
> that the "traditional" model followed by Microsoft and Apple (external
> formal testing and certification with a per-printer fee) is definitely NOT
> acceptable in the much smaller and more fragmented Linux market.
> 
> I took the action item from today's Open Printing Architecture WG
> teleconference to spearhead this topic and to be the principal editor
> as we move forward to specifications.
> 
> The approach we discussed was to gather comments on the
> issues and details, write up a proposed approach, write design
> requirements and specifications for test suites and test tools,
> develop the actual tools, and verify the tools by independent
> testing by several printer vendors and/or ISVs.
> 
> One of the tools should be suitable for use by an end-user (NOT
> a "just recompile everything" geek - but a real typical end-user) to
> verify that a print driver (for example) is correctly installed and that
> all of the dependencies in the complex print system software chain
> are indeed satisfied.
> 
> Cheers,
> - Ira
>