[IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

[IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

[IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

Ira McDonald blueroofmusic at gmail.com
Wed May 25 13:22:11 UTC 2016


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/blueroofmusic
http://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>


More information about the ipp mailing list