Hi Pete,
To your first point:
> 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.".
If there were or are places where I didn't express the finishings in terms of portrait orientation, my apologies - it is likely due to mistakes or typos on my part (e.g. mistakenly using "staple-top-left" where I should have used "staple-bottom-left" or "staple-top-right". I will try to make sure the sequence diagrams I'm working on will accurately specify these values to avoid further misunderstanding.
Mike's responses earlier accurately expressed what we are trying to do here. I am not trying to add support for device specific processing, but rather trying allow the Printer to express limitations to finishings to the Client to give it the ability to present only those facilities that the device supports so that the User's intent can match the capabilities of the Printer, to try to avoid User disappointment.
Smith
> On 2016-05-24, at 6: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.".
>> I would prefer to keep device specific processing out of the protocol whenever possible. 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. I do not want to see these intermediate printers have to transform a print ticket based on which device produces the output. 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.
>> In the definition of IPP we discussed at length whether or not an IPP Printer is a physical or logical/virtual device. We purposely abstracted out as much of the physical device as possible. I would hate to start modeling an IPP Printer as a physical device. Introducing the complexities and variations of physical device implementations will reduce the interoperability of IPP Clients and IPP Printers. It will make the specification of the user's intent more complex. Looking at the Finishings-2.1-Orientation-and-Feed-Orientation-Extensions document, I see nothing that would require a deviation from the current semantics to accomplish the desired output.
>> Peter Zehler
> Xerox Corp.
> Global Development Group
> 800 Phillips Rd, 111-04A
> Webster NY, 14580-9701
> Email: Peter.Zehler at Xerox.com> Office: +1 (585) 265-8755
> Fax: +1 (585) 422-0238
> Mobile: +1 (585) 329-9508
>> -----Original Message-----
> From: ipp [mailto:ipp-bounces at pwg.org] On Behalf Of Kennedy, Smith (Wireless Architect)
> Sent: Monday, May 23, 2016 3:14 PM
> To: ipp at pwg.org> Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted
>> Greetings,
>> This revision of the slide set is now on the FTP site here:
>>http://ftp.pwg.org/pub/pwg/ipp/slides/Finishings-2.1-Orientation-and-Feed-Orientation-Extensions-2016-05-17.pdf>> Smith
>> /**
> Smith Kennedy
> Wireless Architect - Client Software - IPG-PPS
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
> PWG Chair
> HP Inc.
> */
>>>>>>> On 2016-05-17, at 6:16 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>> Greetings,
>>>> Attached is an updated slide set as per the last IPP WG meeting. Please review before next meeting and reply with feedback via email if possible if there are any glaring issues with the way that I've encoded things. This is a complex problem, which would benefit from broad review.
>>>> Cheers,
>>>> Smith
>>>>>>>>> On 2016-04-28, at 10:24 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>>>> Greetings,
>>>>>> I have posted a brief slide set that I will use later today to try to illustrate issue I think needs to be addressed in Finishings 2.1, that concerns managing finishings options based on job orientation and/or feed orientation. It is here:
>>>>>>http://ftp.pwg.org/pub/pwg/ipp/slides/Finishings-2.1-Orientation-and-Feed-Orientation-Extensions.pdf>>>>>> I've also updated the meeting page to list this slide deck.
>>>>>> Cheers,
>>>>>> Smith
>>>>>>> <Finishings-2.1-Orientation-and-Feed-Orientation-Extensions-2016-05-17.pdf>_______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20160524/fa247c23/attachment.p7s>