Smith,
> On Oct 14, 2016, at 5:06 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>> ...
>>> 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.
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.
> 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?**
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.)
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?
>>> 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.
>>>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer