Smith,
I would prefer to have the limitations of finishings for an IPP Printer expressed using the "job-constraints-supported" approach. I believe that tying finishings limitations to physical attributes of the media path is the wrong approach. We have achieved a great deal of flexibility in implementation choices and improved interoperability as a result of treating the IPP Printer as virtual device. There are times when the physical configuration/status of a printer is important. I don't believe that the construction of a print job ticket should be one of those times. Expressing the finishings limitation in terms of the available media is preferable. That way the physical aspects of the printer are factored out. I know we have the tray selections defined for media but that was originally put in for backward compatibility and for very low end devices that have no concept of media. I don't believe any printer supporting IPP does not comprehend media. One of the remaining use cases I see now for specifying media with a tray name is for custom media via the bypass tray.
Pete
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: Kennedy, Smith (Wireless Architect) [mailto:smith.kennedy at hp.com]
Sent: Tuesday, May 24, 2016 2:52 PM
To: Zehler, Peter <Peter.Zehler at xerox.com>
Cc: ipp at pwg.org
Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted
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>