Subject: [IPP] Finishings 2.1 and maximum sheets - is "printer-finisher" "maxsetsheets" enough?

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 13 Oct 2016 22:18:37 +0000

Greetings,

I have been updating the PWG's Finishings specification (PWG 5100.1) to produce Finishings 2.1. One of the additions in this update is the ability for the Printer to state the limits it has on the number of sheets that can be finished. The original Finisher MIB (RFC 3806) has a simple "maximumSheets" attribute that can be used to specify the maximum for the finisher unit itself. We had originally thought that adding a corresponding keyword to "printer-finisher" would be a sufficient solution. But after a few discussions internally, it turns out the maximum number of sheets can vary according to the particular finishing operation itself, not simply according to the finisher accessory. As a simple example, the maximum number of sheets a folder can handle may be 5 sheets for the IPP "finishings" type 'fold-half' but may be only 3 sheets for the IPP "finishings" type 'fold-letter' or 'fold-z'.

Originally I had thought that adding a new "xxx-max-sheets" member attribute to each of the sub-collections of finishings-col (e.g. "baling-max-sheets", "folding-max-sheets", etc.) that allows the Printer to indicate the maximum number of sheets supported for that operation. That may be sufficient.

But there is another issue that seems to be overlooked: not all media types are the same thickness. And by simply providing a number of sheets, we aren't considering the media thickness. Consider a situation where you want to do a booklet printing operation, where the outside cover is made from a different media type than the rest of the pages. The number of sheets doesn't accurately help in this calculation.

To solve the media thickness problem (and to add another layer of complexity, unfortunately) another alternative solution would be to add a new "xxx-max-thickness" member attribute to each of the sub-collections of finishings-col (e.g. "baling-max-thickness", "folding-max-thickness", etc.) that allows the Printer to indicate the maximum set thickness supported for that operation. A Client would consider the number of pages, the media types selected (by consulting "media-col.media-thickness"), and the finishing operations, and would accurately be able to decide whether the number of pages was too great, etc.

Now some vendors have constraints between certain finishing operations and the media types, so that the thicknesses are predictable. But that doesn't really help in actually calculating whether the Job as produced by the Printer will meet the user's expectations.

So we have 3 alternatives:

1. Keep the new "printer-finisher" keyword "maxsetsheets"
2. Eliminate "maxsetsheets" and implement "baling-max-sheets", "folding-max-sheets", etc.
3. Eliminate "maxsetsheets" and implement "baling-max-thickness", "folding-max-thickness", etc.
4. Encourage vendors to use constraints between media type and finishing type to limit the range of thicknesses and ignore the thickness issue

Which way(s) should we go with this? We want something that Clients can and will implement, but we also want the limitations of the Printer to be clearly articulated so that the Client implementation can help the User make informed choices, either automatically or manually.

Thoughts?

Cheers,
 
Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 14 Oct 2016 15:51:52 -0400

Smith,

> On Oct 13, 2016, at 6:18 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

Unfortunately, that isn't something that the Finisher MIB handles... :/

> But there is another issue that seems to be overlooked: not all media types are the same thickness. And by simply providing a number of sheets, we aren't considering the media thickness. Consider a…

As with many things in IPP, the values here are meant as a "best-effort" estimate for typical media for the printer, with the printer typically using a sensor to detect when a tray or finisher is actually full regardless of the number of sheets that have been placed there.

> ...

That would be consistent with the Finisher MIB.

> 2. Eliminate "maxsetsheets" and implement "baling-max-sheets", "folding-max-sheets", etc.

I don't like this as much because it conjoins an abstract finishing process to a physical finisher subunit limit. Since printer-finisher is where we are exposing the finisher subunits, that is where the limit should be reported.

> 3. Eliminate "maxsetsheets" and implement "baling-max-thickness", "folding-max-thickness", etc.

That way lies madness.  Most printers don't implement media-thickness support, even LFPs that would have a genuine need for it.  And what Client is going to pre-process the document and job ticket to determine the final set thickness for finishing? And what printer provides this information via other protocols (SNMP, etc.)?

> 4. Encourage vendors to use constraints between media type and finishing type to limit the range of thicknesses and ignore the thickness issue

I think if a vendor knows that certain media types can't be used with a finisher, then those should be exposed as constraints.  But otherwise I think we just rely on the "best effort" principle.

> Which way(s) should we go with this? We want something that Clients can and will implement, but we also want the limitations of the Printer to be clearly articulated so that the Client implementati…

I think the most useful information for the Client is to know the maximum number of sheets a finisher can handle for typical media, with specific constraints for media as needed.  That handles the 99% use cases without requiring a significant amount of intelligence in the Client along with major changes in how Printers track and report finisher capacity.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 14 Oct 2016 21:06:54 +0000

Thanks for your thoughtful responses, Mike! 

I am fine with abandoning calculation of thicknesses - that seems like it is way over-engineered for what we want to support, at least for now. We will stick with measuring in terms of number of sheets.

However, 

> I don't like this as much because it conjoins an abstract finishing process to a physical finisher subunit limit. Since printer-finisher is where we are exposing the finisher subunits, that is wher…

I'm not quite sure I agree. Yes, we are describing a physical finisher subunit limit. But different limits may pertain to different abstract finishing process. 

Let's discuss user experience / expectations:

Jane has a 5 page document that she would like to print and be folded. She chooses folding, and chooses "fold-half". The printer has expressed that it has a maximum number of 5 sheets for 'fold-half', 3 for 'fold-letter', and 2 for 'fold-accordion'. If she chooses 'fold-letter', what would Jane expect to happen?

A. Warning that there are too many pages for 'fold-letter' and offer to do a 'fold-half'
B. Allow Jane to submit the Job and have the Printer present an error
C. Allow Jane to submit the Job and have the Printer simply not fold the pages

I think B and C are less than optimal. With A, if we use "printer-finisher" and 'maxsetsheets' keyword, then there is only one 'maxsetsheets' value possible for the finisher device. Do we set that to 2 to be on the safe side to be sure to avoid B or C? Or do we express the limit on the number of sheets based on the abstract finishing type, using the "Option 2" like above?**

We could get into some awkward weirdness where we have multiple "virtual finisher devices" each of which can only do one of the finishing operations. But that would be less than optimal.

** (We could probably simplify #2 by adding a new "max-sheets" member to "finishings-col" that would only be allowed when it is in "finishings-col-database" and "finishings-col-ready", rather than creating "folding-max-sheets", etc.)

Smith

> On Oct 14, 2016, at 1:51 PM, Michael Sweet <[email-masked]> wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Sat, 15 Oct 2016 11:22:02 -0400

Smith,

> On Oct 14, 2016, at 5:06 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
>>> ...

Perhaps - I guess the question is whether this is a practical issue that has affected users?  For example, the booklet finishers I've used could fold a partial set and "stack" the folded output such that it didn't matter that the folding mechanism could only handle (for example) 10 sheets at a time.  The only time it became an issue was when you wanted to staple (saddle stitch in the case of booklet printing) since the staple had to be done before the fold.

> I think B and C are less than optimal. With A, if we use "printer-finisher" and 'maxsetsheets' keyword, then there is only one 'maxsetsheets' value possible for the finisher device. Do we set that…

I agree that A is the best outcome, with B or C being the fallback for Clients that don't consult the member attribute in "finishings-col-{database,ready}".

> ** (We could probably simplify #2 by adding a new "max-sheets" member to "finishings-col" that would only be allowed when it is in "finishings-col-database" and "finishings-col-ready", rather than…

I like this idea better rather than separate sub-member attributes in each finishing process collection.

As for naming, how about "media-sheets-supported (rangeOfInteger(0:MAX))" to mirror the "job-media-sheets-supported" Printer Description attribute?

---

From: Ira McDonald <[email-masked]>
Date: Sat, 15 Oct 2016 11:57:34 -0400

Hi,

+1 to Mike's comments.

And I like the symmetry of "media-sheets-supported" for
"finishings-col" with "job-media-sheets-supported" for
Printer.

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: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sat, Oct 15, 2016 at 11:22 AM, Michael Sweet <[email-masked]> wrote:

> >> I don't like this as much because it conjoins an abstract finishing
> process to a physical finisher subunit limit. Since printer-finisher is
> where we are exposing the finisher subunits, that is where the limit should
> be reported.
> >
> > I'm not quite sure I agree. Yes, we are describing a physical finisher
> subunit limit. But different limits may pertain to different abstract
> finishing process.
>
> Perhaps - I guess the question is whether this is a practical issue that
> has affected users?  For example, the booklet finishers I've used could
> fold a partial set and "stack" the folded output such that it didn't matter
> that the folding mechanism could only handle (for example) 10 sheets at a
> time.  The only time it became an issue was when you wanted to staple
> (saddle stitch in the case of booklet printing) since the staple had to be
> done before the fold.
>
> > Jane has a 5 page document that she would like to print and be folded.
> She chooses folding, and chooses "fold-half". The printer has expressed
> that it has a maximum number of 5 sheets for 'fold-half', 3 for
> 'fold-letter', and 2 for 'fold-accordion'. If she chooses 'fold-letter',
> what would Jane expect to happen?
> >
> > I think B and C are less than optimal. With A, if we use
> "printer-finisher" and 'maxsetsheets' keyword, then there is only one
> 'maxsetsheets' value possible for the finisher device. Do we set that to 2
> to be on the safe side to be sure to avoid B or C? Or do we express the
> limit on the number of sheets based on the abstract finishing type, using
> the "Option 2" like above?**
>
> I agree that A is the best outcome, with B or C being the fallback for
> Clients that don't consult the member attribute in
> "finishings-col-{database,ready}".
>
> > We could get into some awkward weirdness where we have multiple "virtual
> finisher devices" each of which can only do one of the finishing
> operations. But that would be less than optimal.
> >
> >
> > ** (We could probably simplify #2 by adding a new "max-sheets" member to
> "finishings-col" that would only be allowed when it is in
> "finishings-col-database" and "finishings-col-ready", rather than creating
> "folding-max-sheets", etc.)
>
> As for naming, how about "media-sheets-supported (rangeOfInteger(0:MAX))"
> to mirror the "job-media-sheets-supported" Printer Description attribute?
>
> >
> >
> > Smith
> >
> >> I don't like this as much because it conjoins an abstract finishing
> process to a physical finisher subunit limit. Since printer-finisher is
> where we are exposing the finisher subunits, that is where the limit should
> be reported.
> >>
> >> That way lies madness.  Most printers don't implement media-thickness
> support, even LFPs that would have a genuine need for it.  And what Client
> is going to pre-process the document and job ticket to determine the final
> set thickness for finishing? And what printer provides this information via
> other protocols (SNMP, etc.)?
> >>
> >>> 4. Encourage vendors to use constraints between media type and
> finishing type to limit the range of thicknesses and ignore the thickness
> issue
> >>
> >> I think if a vendor knows that certain media types can't be used with a
> finisher, then those should be exposed as constraints.  But otherwise I
> think we just rely on the "best effort" principle.
> >>
> >>> Which way(s) should we go with this? We want something that Clients
> can and will implement, but we also want the limitations of the Printer to
> be clearly articulated so that the Client implementation can help the User
> make informed choices, either automatically or manually.
> >>
> >> I think the most useful information for the Client is to know the
> maximum number of sheets a finisher can handle for typical media, with
> specific constraints for media as needed.  That handles the 99% use cases
> without requiring a significant amount of intelligence in the Client along
> with major changes in how Printers track and report finisher capacity.
> >>
> >
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Sun, 16 Oct 2016 03:51:29 +0000

I also like Mike's proposal for naming. I will add "media-sheets-supported(rangeOfInteger(0:MAX))" as a member attribute of "finishings-col" and remove "maxsetsheets" from "printer-description" in my next revision, which I hope to have out early this coming week.

Smith

> On Oct 15, 2016, at 9:57 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> +1 to Mike's comments.
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Sat, Oct 15, 2016 at 11:22 AM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> Smith,
> 
> > On Oct 14, 2016, at 5:06 PM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
> >>> ...
> >> On Oct 14, 2016, at 1:51 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>