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

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

[Ira McDonald]

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

-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: blueroofmusic@gmail.com

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

[SHIDA, Keisho]

Ira:

I believe that we need the time out for the discussion of certifying 
the printer and printer drivers. The certification is 

We have to realize that the environment of Linux based desktop for 
office or home use system need the certification for its host PC, 
Linux OS, applications and I/O peripherals in prior to discussion 
of the certifying the printer and its driver.

As you know already, the environment and conditions that surround 
the printer is NOT ready to certify before we discuss the certifying 
the printer.

If these items such described in the above are fruitful enough in the 
street, we may be ready to discuss the printer related certification. 
The printer related items are not stand at the front row of stage, 
we stand at the third or may be fourth row. Please let me know if any 
of these items/products are certified already and available now to 
certifying the printer and its driver. 

For your information, once they are certified or issue the certification 
(logo), all incurred necessary support and the responsibility have to 
taken by an individual manufacturer not community or us.

The certification is one of the priority of LF business or activity plan? 
If so, let’s identify the background and discuss them.

regards


Shida/
===


On Wed, 11 Jul 2007 17:41:31 -0500
"Ira McDonald" <blueroofmusic@gmail.com> 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
> 
> -- 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: blueroofmusic@gmail.com
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture

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

[Ira McDonald]

Hi Shida-san,

Are you saying that we (Open Printing) should NOT discuss the
topic of self-certification of printers and printer drivers on Linux
until AFTER all of those other certification topics you list below
are finished?

Glen Petrie (Epson) and Chris Story (Ricoh) both feel strongly
that we should address printer/driver self-certification and soon,
so that we are not trapped into a plan that arises from Linux
Foundation or elsewhere for external formal certification.

Comments?

Cheers,
- Ira

On 7/12/07, SHIDA, Keisho <shida.keisho@canon.co.jp> wrote:
> Ira:
>
> I believe that we need the time out for the discussion of certifying
> the printer and printer drivers. The certification is
>
> We have to realize that the environment of Linux based desktop for
> office or home use system need the certification for its host PC,
> Linux OS, applications and I/O peripherals in prior to discussion
> of the certifying the printer and its driver.
>
> As you know already, the environment and conditions that surround
> the printer is NOT ready to certify before we discuss the certifying
> the printer.
>
> If these items such described in the above are fruitful enough in the
> street, we may be ready to discuss the printer related certification.
> The printer related items are not stand at the front row of stage,
> we stand at the third or may be fourth row. Please let me know if any
> of these items/products are certified already and available now to
> certifying the printer and its driver.
>
> For your information, once they are certified or issue the certification
> (logo), all incurred necessary support and the responsibility have to
> taken by an individual manufacturer not community or us.
>
> The certification is one of the priority of LF business or activity plan?
> If so, let's identify the background and discuss them.
>
> regards
>
>
> Shida/
> ===
>
>
> On Wed, 11 Jul 2007 17:41:31 -0500
> "Ira McDonald" <blueroofmusic@gmail.com> 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
> >
> > --
> > Ira McDonald (Musician / Software Architect)
> > Chair - Linux Foundation Open Printing WG
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: blueroofmusic@gmail.com
> >
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.freestandards.org
> > http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
>
>
>


-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: blueroofmusic@gmail.com

Re: [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
> 

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

[SHIDA, Keisho]

Ira:

I did not check the email before the meeting took place in 
this morning/ Here is answer to you’re your point

NO, I am not saying that not discussing as OP topics.
My point is as follow:

1.We have to identify and check the environment and 
configuration that have to be done before or clearly identified 
prior to the discussion of printing related topics.

2.We have to ask PC manufacturers, Linux OS distributors 
and application developers to join the discussion.

3.I am still in the foggy bottom to understand the effort of 
“validation”. Is this for a user? distributor? app vendor? or 
printer manufacturer? If it is for the user, I believe that we
 have to study this topic as user point of view or use-case.

4.Why they are talking about printer “validation” in front? 
And who are they? And what their purpose?

Well, I believe that we, as SC members, agreed to discuss and 
study this topic in further but we need more manufacturers in 
present or ask them to join some special telecon meeting.


Regards,


Shida
===

On Fri, 13 Jul 2007 10:29:16 -0500
"Ira McDonald" <blueroofmusic@gmail.com> wrote:

> Hi Shida-san,
> 
> Are you saying that we (Open Printing) should NOT discuss the
> topic of self-certification of printers and printer drivers on Linux
> until AFTER all of those other certification topics you list below
> are finished?
> 
> Glen Petrie (Epson) and Chris Story (Ricoh) both feel strongly
> that we should address printer/driver self-certification and soon,
> so that we are not trapped into a plan that arises from Linux
> Foundation or elsewhere for external formal certification.
> 
> Comments?
> 
> Cheers,
> - Ira
> 
> On 7/12/07, SHIDA, Keisho <shida.keisho@canon.co.jp> wrote:
> > Ira:
> >
> > I believe that we need the time out for the discussion of certifying
> > the printer and printer drivers. The certification is
> >
> > We have to realize that the environment of Linux based desktop for
> > office or home use system need the certification for its host PC,
> > Linux OS, applications and I/O peripherals in prior to discussion
> > of the certifying the printer and its driver.
> >
> > As you know already, the environment and conditions that surround
> > the printer is NOT ready to certify before we discuss the certifying
> > the printer.
> >
> > If these items such described in the above are fruitful enough in the
> > street, we may be ready to discuss the printer related certification.
> > The printer related items are not stand at the front row of stage,
> > we stand at the third or may be fourth row. Please let me know if any
> > of these items/products are certified already and available now to
> > certifying the printer and its driver.
> >
> > For your information, once they are certified or issue the certification
> > (logo), all incurred necessary support and the responsibility have to
> > taken by an individual manufacturer not community or us.
> >
> > The certification is one of the priority of LF business or activity plan?
> > If so, let's identify the background and discuss them.
> >
> > regards
> >
> >
> > Shida/
> > ===
> >
> >
> > On Wed, 11 Jul 2007 17:41:31 -0500
> > "Ira McDonald" <blueroofmusic@gmail.com> 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
> > >
> > > --
> > > Ira McDonald (Musician / Software Architect)
> > > Chair - Linux Foundation Open Printing WG
> > > Blue Roof Music / High North Inc
> > > PO Box 221  Grand Marais, MI  49839
> > > phone: +1-906-494-2434
> > > email: blueroofmusic@gmail.com
> > >
> > > _______________________________________________
> > > Printing-architecture mailing list
> > > Printing-architecture@lists.freestandards.org
> > > http://lists.freestandards.org/mailman/listinfo/printing-architecture
> >
> >
> >
> >
> 
> 
> -- 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: blueroofmusic@gmail.com

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

[Ira McDonald]

Hi Shida-san,

"They" are Linux Foundation people who are interested in creating
various "certification" programs.  For example, a hypothetical "LSB
Print Certificate".

Chris Story (Ricoh) first pushed back hard on this idea.  Thus, we
(Open Printing) are talking about "validation" of print drivers and
printers for Linux/POSIX platforms.

As I said at our OP SC, target users for OP Validation tools are:

- Manufacturers - validate their PPDs and drivers and scripts
- Distributions - regression test/validate their build CDs
- ISVs - validate their applications (e.g., Scribus) for printing
- End Users - validate/debug installed print drivers/environment

Not all target users will use the same tool or script and for
End Users I agree that we will need to identify test apps and
test documents.

Cheers,
- Ira


On 7/16/07, SHIDA, Keisho <shida.keisho@canon.co.jp> wrote:
> Ira:
>
> I did not check the email before the meeting took place in
> this morning/ Here is answer to you're your point
>
> NO, I am not saying that not discussing as OP topics.
> My point is as follow:
>
> 1.We have to identify and check the environment and
> configuration that have to be done before or clearly identified
> prior to the discussion of printing related topics.
>
> 2.We have to ask PC manufacturers, Linux OS distributors
> and application developers to join the discussion.
>
> 3.I am still in the foggy bottom to understand the effort of
> "validation". Is this for a user? distributor? app vendor? or
> printer manufacturer? If it is for the user, I believe that we
>  have to study this topic as user point of view or use-case.
>
> 4.Why they are talking about printer "validation" in front?
> And who are they? And what their purpose?
>
> Well, I believe that we, as SC members, agreed to discuss and
> study this topic in further but we need more manufacturers in
> present or ask them to join some special telecon meeting.
>
>
> Regards,
>
>
> Shida
> ===
>
> On Fri, 13 Jul 2007 10:29:16 -0500
> "Ira McDonald" <blueroofmusic@gmail.com> wrote:
>
> > Hi Shida-san,
> >
> > Are you saying that we (Open Printing) should NOT discuss the
> > topic of self-certification of printers and printer drivers on Linux
> > until AFTER all of those other certification topics you list below
> > are finished?
> >
> > Glen Petrie (Epson) and Chris Story (Ricoh) both feel strongly
> > that we should address printer/driver self-certification and soon,
> > so that we are not trapped into a plan that arises from Linux
> > Foundation or elsewhere for external formal certification.
> >
> > Comments?
> >
> > Cheers,
> > - Ira
> >
> > On 7/12/07, SHIDA, Keisho <shida.keisho@canon.co.jp> wrote:
> > > Ira:
> > >
> > > I believe that we need the time out for the discussion of certifying
> > > the printer and printer drivers. The certification is
> > >
> > > We have to realize that the environment of Linux based desktop for
> > > office or home use system need the certification for its host PC,
> > > Linux OS, applications and I/O peripherals in prior to discussion
> > > of the certifying the printer and its driver.
> > >
> > > As you know already, the environment and conditions that surround
> > > the printer is NOT ready to certify before we discuss the certifying
> > > the printer.
> > >
> > > If these items such described in the above are fruitful enough in the
> > > street, we may be ready to discuss the printer related certification.
> > > The printer related items are not stand at the front row of stage,
> > > we stand at the third or may be fourth row. Please let me know if any
> > > of these items/products are certified already and available now to
> > > certifying the printer and its driver.
> > >
> > > For your information, once they are certified or issue the certification
> > > (logo), all incurred necessary support and the responsibility have to
> > > taken by an individual manufacturer not community or us.
> > >
> > > The certification is one of the priority of LF business or activity plan?
> > > If so, let's identify the background and discuss them.
> > >
> > > regards
> > >
> > >
> > > Shida/
> > > ===
> > >
> > >
> > > On Wed, 11 Jul 2007 17:41:31 -0500
> > > "Ira McDonald" <blueroofmusic@gmail.com> 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
> > > >
> > > > --
> > > > Ira McDonald (Musician / Software Architect)
> > > > Chair - Linux Foundation Open Printing WG
> > > > Blue Roof Music / High North Inc
> > > > PO Box 221  Grand Marais, MI  49839
> > > > phone: +1-906-494-2434
> > > > email: blueroofmusic@gmail.com
> > > >
> > > > _______________________________________________
> > > > Printing-architecture mailing list
> > > > Printing-architecture@lists.freestandards.org
> > > > http://lists.freestandards.org/mailman/listinfo/printing-architecture
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Ira McDonald (Musician / Software Architect)
> > Chair - Linux Foundation Open Printing WG
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: blueroofmusic@gmail.com
>
>
>
>


-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: blueroofmusic@gmail.com

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

[Marcelo Ricardo Leitner]

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.

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

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

Thanks,
Marcelo.

Re: [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

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

[Marcelo Ricardo Leitner]

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

On Ter Jul 17, 2007 at 23:55:12 +0100, Till Kamppeter wrote:
> Marcelo Ricardo Leitner wrote:
>> Hi all,
>> On Fri Jul 13, 2007 at 16:42:33 +0100, Till Kamppeter wrote:
>>>
>>> - 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).

I though I had lost it, but searching again I found it. It's the tarball
attached. It includes 3 quick scripts:
check-printers-all.sh: checks for all drivers for all printers
check-printers.sh: checks the recommended driver for all printers
filter: filters(sort in dirs) out the logs according to the errors

Sorry for the dust, these scripts weren't touched for the last 2 years. But
they should be functional yet. :)

They already use foomatic-configure to setup the queues, as it makes it
easier, but it relies on the CUPS error logging, so it's CUPS-specific
because of this.

The spooler-less option would be nice, so you can know very precisely if
it's the driver or the driver+spooler combination that's not working.

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

Specially now with CUPS 1.3 side's channel for backend/filter communication,
we could enforce this design usage by someway (working with upstream
perhaps), unless we won't be able to certify these drivers.

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

So it would be mostly a GUI for all other test suits, right?

Thanks,
Marcelo.

[-- Attachment #2: printing-tests.tar.gz --]
[-- Type: application/octet-stream, Size: 1953 bytes --]