Daniel,
Thank you for posting the minutes, some feedback on Copy below (and hoping that I can find time to call in for the next meeting...)
On Jul 2, 2013, at 7:45 PM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:
> ...
> 1. Do we need to have a separate Copy Service? The reason to have a separate Copy Service is that there are hardware optimizations that take place in a copy job that are not available to print.
Such as?
> Modeling copy as print requires intermediate image storage from the AddHardCopyDocument to the time the print job is scheduled.
Why? For a Printer that only allows a single job at a time (the vast majority of printers), AddHardcopyDocument could stream the image data from the scanner to the print engine just as if a Client was streaming via Send-Document. No intermediate storage is required.
And certainly if a Printer *does* support spooling of multiple jobs a Copy service job will wait in queue just as effectively as a Print service job - again, I don't see the need to force intermediate storage of the scanned document, it would just be an implementation choice.
> A copyjob does not suffer that sub-optimal image flow construct. Users are very familiar with copy and would be confused with a copy job showing up in a print queue.
More confused than seeing their print job wait for an unknown reason? Both Print and Copy use the marker, but if somebody is making 100 copies of a 50 page presentation the user sending a print job could be waiting for a long time wondering why their job isn't printing. If instead they see a print job in the queue (for the copy) they will understand why their job isn't printing.
> The normal use case for a copy job is the walk up user who is physically present on the device.
Right, and that user doesn't care how the printer performs the copy, just that they get the copies they want.
> A related issue is that lumping copy in with print diminishes the ability to monitor, manage and charge for copies.
Why? Can't we provide Job History for Print Jobs that have a hardcopy document?
> More over additional IPP FaxOut and EmailOut (scan elements / aspects) are presently adhoc and could be brought into a Copy Service.
I'm not sure I understand this comment.
The current CopyInTicket and CopyOutTicket try to overload the processing intent for both input and output. This makes it impossible for a generic print client to initiate a copy - fairly extensive modifications are necessary. FaxOut and EmailOut, in comparison, require only modest changes to add UI to specify the destination of the fax or email, and optionally UI to support selection of a hardcopy document instead of a local document or accessible URL.
If we implement Copy through the Print service with AddHardcopyDocument, the same print client and UI for Print, FaxOut, and EMailOut can be reused, the user can monitor both print and copy jobs in one place/queue, and the Imaging Device has one less service to maintain separately with slightly different semantics from the others.
There *are* some elements from CopyInTicket that are not present in InputElements/input-attributes - this I noted in the current IPP FaxOut specification. But the current SM FaxOut specification only allows specification of InputSource, which is clearly deficient.
As a function of normalizing the Semantic Model I think the answer here is to formally define what a hardcopy document is, how hardcopy documents are processed, and what the standard/common elements are for all services that create (scan) them. We then use those common elements and semantics across all services that support hardcopy documents. Once we have done that I believe the perceived necessity of a Copy service will fade away.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20130703/bbf31834/attachment-0002.html>