Hi,
Like Pete, I endorse Mike's suggestion of considering using Job Constraints,
rather than muddying media-col-database or finishings-col-database/ready.
Directly accessible Printers (USB or local network domain) can provide more
info to IPP Clients about physical characteristics, but in the context of
Job
forwarding, Cloud/SDN print, etc. it's preferable to stick firmly to
intent-based
printing, IMO.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, May 25, 2016 at 7:34 AM, Zehler, Peter <Peter.Zehler at xerox.com>
wrote:
> 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> >
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20160525/69ccf4b5/attachment.html>