[Printing-architecture] RE: [Printing-summit] Printing Path validation tool

[Petrie, Glen]

Actually, Print Vendors want a test application that is completely
independent of other software entities.   This would include any print
manager, print spooler, transform, etc.   If an entity, like the
OpenPrinting working group, defines "what is the required results/"; then,
the Print Vendor can write the test application for the Vendors specific
printers.  Then, there would exist something like the EpsonPrinterTest,
HPPrinterTest, CanonPrinterTest, etc.  Where the program argument is the
printer model to test.   If a third party wants to provide a driver; say me,
then the test application might be called GlenEpsonPrinterTest and
GlenHPPrinterTest, etc. GutenPrint might look like GutenEpsonPrinterTest,
etc.   The distro would contain a single directory with the "Printer" test
applications.

For Distro's, they will need another program to test "Printing" which
includes the print-path and the printer-driver.  This application may have
to test many paths depending on what print managers; print spoolers; and
transforms are defined and supported by an individual distro.   

I believe that if the print-vendors (and, perhaps, the distro's) test the
driver for supported printers that the Distro's "Printing" test application
does not have to output to a physical printer (or to the driver) but simply
to a file.  The file is then expected to have a pre-determinable content.
Thus, the application can test a very wide variation of "Printing" paths
with physically having to have every printer.

glen

-----Original Message-----
From: printing-summit-bounces at lists.linux-foundation.org
[mailto:printing-summit-bounces at lists.linux-foundation.org] On Behalf Of
Michael R Sweet
Sent: Thursday, September 27, 2007 3:28 PM
To: Marcelo Ricardo Leitner
Cc: printing-summit at lists.freestandards.org
Subject: Re: [Printing-summit] Printing Path validation tool

Marcelo Ricardo Leitner wrote:
> Michael R Sweet wrote:
>> Marcelo Ricardo Leitner wrote:
>>> ...
>>> Actually, we would just have to make a change in CUPS logging system: 
>>> make it detailed logs per queue per job. I mean:
>>>
>>> 1) Create a file with all those "[ Job XX ]" messages, and only those.
>>
>> CUPS (as of 1.3) prefixes ALL job-related log messages with "[Job N]"
>> so you can just grep.
> I can't check nows, sorry, but perhaps CUPS > 1.3.0, as the example 
> message I pasted was generated by a CUPS 1.3.0.

No, 1.3.0 and higher.  The PID message isn't tagged, but there is a
corresponding job status message that *is* tagged...

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer
_______________________________________________
Printing-summit mailing list
Printing-summit at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/printing-summit