My comments are inline below.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Wednesday, July 03, 2013 9:15 AM
To: Manchala, Daniel
Cc: mfd at pwg.org
Subject: Re: [MFD] Meeting Minutes: IEEE/ISTO – PWG/Semantic Model Working Group, 1 July 2013
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<mailto: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?
<PZ>Scanning image into a proprietary format that is device specific. Vendors may wish to keep details of such a format private. There are optimizations that might be used for the transfer channel between the scanning subunit and the marker subunit. Several steps in the print service can be eliminated.</PZ>
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.
<PZ>There are many printers that support queuing multiple jobs at a time. There are printers capable of processing multiple jobs at a time. Don’t take a proven scalable model and protocol and constrain its capability based on a subset of the market. Adding a Hard Copy Document to a job does not require streaming the image data to the print engine. I see nothing in the model or protocol from allowing the addition of documents to a pending or pending-held job. Keep in mind that an open job (i.e., no CloseJob operation received) cannot be the scheduled or be the currently active job. Also keep in mind that AddHardCopyDocument is an illegal operation on a closed job.</PZ>
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. <PZ>A Copy Service Job does not wait as effectively in a print Service queue. A copy job is constructed at the device meaning the documents within the job are added during the construction of the job. There are MFDs that provide a very rich set of document assembly choices for copy jobs. It is not always just putting a page on the platen and pressing copy. Even if intermediate storage is not required there are reasons stated above and below to treat a copy job as a copy job and not some modified print job. />
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.
<PZ>Why would a JobStateReason of ‘JobQueueForMarker’ be any more confusing than ‘PrinterStopped’ when there is a paper jam. Naturally the Client software would present that to the user in an understandable format. Sooner or later there will have to be a service to show user’s the unified view of the MFD. Why shouldn’t a user be able to see a unified queue of all the jobs on an MFD?</PZ>
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.
<PZ>Printers don’t perform copies, MFDs or Copiers do. The workflow at the device may be quite different when trying to copy on an inactive device or on a device that is currently printing a job. There may also be differences when trying to print pictures from a SD memory card versus copying a picture. User’s don’t care how an MFD does anything, they just want their output. But service provider do care how the jobs and services are represented in the model.
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?
<PZ>It certainly complicates the ability to pause/resume and enable/disable individual services. It makes it more complicated to check to see if a service is available. It makes it more difficult to establish policy for users a specific service. There are real world needs to independently control printing and copying and faxing on an installed MFD. It will break the existing Standardized Imaging System Counters and associated MIB standards.</PZ>
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.
<PZ>Adding a hardcopy document should be consistent across the services that deal with hard copy input (e.g., scan, faxout, copy).</PZ>
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.
<PZ>A generic Print Client should not be initiating a copy. Print Job certainly cover the output side (i.e., Print), but it does not cover the input side (i.e., Scan). I disagree that the only changes to print for fax or email are limited to the selection of the hardcopy document. Certainly a low-end implementation could do that. Higher end clients would want the ability to correct things like brightness, contrast, and sharpness.</PZ>
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.
<PZ>Print, Scan, Copy, FaxIn, and FaxOut are different and should be handled separately. EmailIn and EmailOut are an awful lot like FaxIn and FaxOut and since I have seen no strong pull for them I’ll ignore them for now. If the objective is to have an MFD client then one solution would be to implement a unifying view into the services. Another solution would be to extend 5108.06 to provide a unified queue with the usual queue operations. I see no reason to abandon the model or to try and shoehorn separate services into one. The Service, Job, and Document objects are similar enough to provide a unified view.
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.
<PZ>This is a good opportunity to normalize the specification of hard copy input document processing.</PZ>
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<http://www.mailscanner.info/>, and is
believed to be clean.
--
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/9fb270c0/attachment-0002.html>