attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks for your thoughtful responses, Mike! <div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">However, </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">2. Eliminate "maxsetsheets" and implement "baling-max-sheets", "folding-max-sheets", etc.</div></div></blockquote></div></div></div></blockquote><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Let's discuss user experience / expectations:</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">A. Warning that there are too many pages for 'fold-letter' and offer to do a 'fold-half'</div><div class="">B. Allow Jane to submit the Job and have the Printer present an error</div><div class="">C. Allow Jane to submit the Job and have the Printer simply not fold the pages</div><div class=""><br class=""></div><div class="">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?**</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">** (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.)</div></div></div></div></div><div class=""><br class=""><div class=""><br class=""><div class="">
Smith<br class="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 1:51 PM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class="" style="font-family: ArialMT; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="">So we have 3 alternatives:<br class=""><br class="">1. Keep the new "printer-finisher" keyword "maxsetsheets"<br class=""></div></div></blockquote><div style="font-family: ArialMT; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: ArialMT; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">That would be consistent with the Finisher MIB.</span></div></div></div></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">2. Eliminate "maxsetsheets" and implement "baling-max-sheets", "folding-max-sheets", etc.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">3. Eliminate "maxsetsheets" and implement "baling-max-thickness", "folding-max-thickness", etc.<br class=""></div></div></blockquote><div class=""><br class=""></div>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.)?</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">4. Encourage vendors to use constraints between media type and finishing type to limit the range of thicknesses and ignore the thickness issue<br class=""></div></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""></div></div></blockquote><div class=""><br class=""></div></div>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.</div></div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""></div></div></div></body></html>