Pete,
On Jul 3, 2013, at 10:55 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> ...
> 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?
> <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>
How does adding a hardcopy document to a print job prevent any of those optimizations from happening?
The hardcopy document can be represented internally in any format by the implementation - this is part of the existing model.
The implementation controls the transfer channel between the scanning subunit and the marker subunit. Nothing in the model (or my proposed addition to Print to support the copy use case) would prevent the imaging device from using a proprietary format, optimized transfer channel, or magic pixie dust to optimize that imaging path, even on devices that support spooling of multiple jobs.
So which steps are we eliminating by using a Copy service vs. a Print service that supports hardcopy documents?
> 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>
OK, so going back to my last point about defining what a hardcopy job is, what is wrong with defining a document object that has a reference to an internal resource (the scanner) that is resolved (scanned) when it goes into the processing state? This matches what we do for printing with URIs, doesn't require a document to be added to a closed job, and allows the implementation to determine when the hardcopy document is scanned and either stored or streamed to the marker subunit?
I am by no means trying to constrain the model - I actually want printers to be MORE capable, not less - but am rather trying to simplify and unify support for hardcopy documents in the model, something that we have (thus far) shoved off into the corner as an edge case that effectively needs special software and works in slightly different and incompatible ways.
So please consider the following: rather than assuming the only way to support the copy use case is with a first class Copy service, let's revisit hardcopy documents *first* and come up with a consistent model to support them for all services that can use them.
That will yield a more consistent and feature-rich interface for Scan, FaxOut, and EmailOut. It may also make the decision of whether we need a first-class Copy service more clear.
> 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. />
Again, I haven't read anything that would preclude the Print service performing all of the functions of the Copy service.
> 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>
No reason, it is just that much more work for the Client to do if there is this extra service that sort-of works like the others, puts things in different places, and has no documents. Copy has been as a special-case service that has to do things differently, yet when you look at what the Copy service does it isn't clear why this has to be so.
> 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 user *might* call it a copier. I don't know that anyone makes the distinction of "MFD" or "MFP" - I'm in the printing engineering department of Apple and *we* just say "I'll make a copy at the printer."
So my use of casual terminology aside, you are very effectively making MY point - hardcopy documents are not currently represented in the model. In FaxOut we added Add<service>HardcopyDocument to represent hardcopy documents in FaxOut jobs, and in Copy we waved our hand and said "these are not the documents you are looking for".
We absolutely need to be able to represent hardcopy documents in the model. They are not currently represented. Once we *do* represent them we can support directly them in the Print, Scan, FaxOut, and EmailOut services - at that point does it still make sense to have a separate Copy service? Maybe so, maybe not. I just don't think it is a foregone conclusion that one *is* absolutely required. And if we *do* end up with a Copy service, it should have jobs with one or more (hardcopy) document objects, just like the other services.
> 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.
How?
If you are using the Copy service as a way to provide access control (disable copy service, nobody can copy from the Imaging Device?) then I suggest that we work in IDS to define proper access control mechanisms.
> It makes it more complicated to check to see if a service is available.
Again, are you trying to query an access control policy? Or supported operations (copy disabled means Add<service>HardcopyDocument is not supported)?
> 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.
Agreed. But having implemented arbitrarily complex ACLs for CUPS, I don't think separate functional services are necessarily the answer. But I *do* think that the current Copy service model isn't the answer.
> It will break the existing Standardized Imaging System Counters and associated MIB standards.</PZ>
How so? The system-level (SystemTotals) counters don't break out Copy counts, just total impressions and so forth. The Job MIB and various counters are broken out by service types (and not necessarily services - for example FaxIn vs. NetworkFaxIn, which are both supported by the single FaxIn service).
> 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>
I'm in 100% agreement.
> 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.
Because???
(how many smart phone/tablet applications are there from every printer vendor that allow you to print, scan, fax, copy, etc.?)
> 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>
Sure, but that is all common to scanning - something that a client will likely want to do with a multifunction Imaging Device. And something that presumably will be done using common code in the client to support Imaging Devices.
> 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.
We can argue whether the same UI gets used for print, fax, email, etc., but that's not my specific focus. Underneath the UI, the same code ends up getting used (to generate the paged data, to talk to the local service(s), to talk to the Imaging Device), and generally the HI guys want to present a similar user experience for dealing with documents and Imaging Devices.
I'm not arguing for a single meta service that does everything. Nor am I arguing for a single UI to support all functions of an Imaging Device. Rather, I am arguing for a consistent, well-defined model of Imaging Devices that can be implemented and interoperable, without a lot of special casing.
Maybe we need a Copy service, maybe we don't. But if we do, it should be consistent with the rest of the job-based services.
> 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>
Again, we're in 100% agreement here.
_________________________________________________________
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/6981bd27/attachment-0002.html>