Pete,
> On May 24, 2016, at 8:22 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> All,
>> I don't understand why the long established method of specifying finishing by intent is being modified to a process based model. RFC2911 stated "specified with respect to the document as if the document were a portrait document. If the document is actually a landscape or a reverse-landscape document, the client supplies the appropriate transformed value.". PWG5100.1 clarified that "The approach for the coordinate system of being relative to the media feed direction is too dependent on the way the device is configured, i.e., pulling short edge first vs. long edge first, and can vary between different output bins in the same device.". I'd also note that the semantics adopted by the PWG provide consistence not only between RFC2911 and PWG5100.1 but with the finisher MIB RFC3806 which states "All Finishing Processes are defined relative to a portrait orientation of the medium, regardless of the orientation of the printed image or the direction of feed.".
The issue is not one of specifying the processing details in the Job Ticket, but communicating the device constraints in finishings-col-database/ready (along with details that allow the Client to preview the results of finishing processes/intent).
> I would prefer to keep device specific processing out of the protocol whenever possible.
That is definitely the sticking point in this discussion - I completely agree that we want to avoid exposing low-level device processing details, but at the same time we want to provide enough information to the Client to know about hardware limitations/constraints.
> IPP printers support fan out. There is a "walk and request" (aka Follow Me Print) mode of printing system in which a user can walk to any printer in the network pool and request that his or her job be released and printed at that particular printer. Fan out also applies to printer clustering to increase resource utilization.
"Follow me" or "release" printing generally has a lower expectation of fidelity, and often the printing system will only expose a common subset of printer features and capabilities as configured by the administrator, e.g., all printers are configured with duplex, letter/a4, tabloid/a3, and a stapler. In this case the printing system would not provide device-specific constraints but simply represent the generic finishing capabilities.
Printer clusters often involve multiple identical printers and/or fan-out jobs to printers that support the requested Job Ticket intent, e.g., Tabloid booklet fold jobs get routed to a printer that supports that media size, booklet fold, and saddle stitch.
> I do not want to see these intermediate printers have to transform a print ticket based on which device produces the output.
I think we are in agreement for this - to reiterate my original point, the member attributes under discussion provide descriptive values for finishings-col-database/ready Printer Status attributes and cannot be supplied in the finishings-col Job Template attribute.
> There are printers that support feeding the same media both long edge and short edge depending upon the tray from which the media is pulled. These printers already must handle the transformation of the print job intent to the process necessary to produce the appropriate output. This applies not only to job ticket elements but to job content as well.
The kicker is that a Client can specify the desired input tray via the "media-source" member attribute in the "media-col" Job Template attribute. Including some constraint information in "finishings-col-database/ready" allows the Client to present a choice to the user (or limit the choices available to the user) depending on the selected media and finishings values.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer