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,
>> 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.
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 <msweet at apple.com> wrote:
>>> So we have 3 alternatives:
>>>> 1. Keep the new "printer-finisher" keyword "maxsetsheets"
>> 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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161014/86de2ded/attachment.html>
-------------- 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/20161014/86de2ded/attachment.p7s>