Smith,
> On Oct 13, 2016, at 6:18 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> 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'.
Unfortunately, that isn't something that the Finisher MIB handles... :/
> 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.
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.
> ...
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161014/695f9150/attachment.html>