Overview

The PWG Finisher MIB meeting took place Friday, 3/6/98, in Austin. Tom Hastings proposed to reduce the number of objects to an absolute minimum (4), leaving everything else as an optional attribute. While this would result in extreme flexibility, it would leave application writers with little reliable structure or content. We decided to pursue more balance between objects and attributes by defining a mandatory set of objects and relegating any optional information to the list of attributes. We worked through some of this at the meeting. Tom and Ron will complete this effort and post the updated draft.

Carlos Becerra joined us, from HP, and was very helpful in sharing his finisher expertise. We hope to increase our finisher industry participation by inviting the following list of manufactures:

Issues Discussed and Recorded

The following list of issues was posted and reviewed with the results documented, herein.

1. Staple position and Finishing axis. These definitions are intended to align with DPA, however, we need to do a thorough comparison and complete our diagrams and documentation. Ron and Harry to handle.

2. Finishing attributes. We reviewed attributes, like punch patterns, considering the pro's and con's of naming vs. identification by metrics. We learned that some (high-end) finishers allow custom configuration and recall with localized names. For example, Hospitals use a special 5 hole punch at the top of the sheet to form a portrait ledger.

We decided to establish an extensible naming scheme (customHolePattern1 through customHolePatternN), but hope that more Finisher vendors will participate, helping us complete the list of finishing attributes and adopt the appropriate semantics.

3. DefVALs. Should they be used to define the finishing defaults?

4. Finishing types without attributes. There are currently no attributes for Trimmer, Die Cutter, Perforator, Separator, Imprinter, and Bander.

5. MIB Structure. Should the optional Extended Finisher Device Group be defined as a NEW table that AUGMENTS the Finisher Device Group table? The Printer MIB may be the only MIB that defines subsets of an ENTRY sequence as optional. This is may be incorrect MIB design which we might want to avoid. Also pertains to Finisher Supply Media, and Extended Input Groups.

Do we keep as is, since it is patterned after the Printer MIB, change, or remove?

As part of the compromise between mandatory object and attributes, it is recommended to

move the Extended Finisher Device Group to the attribute section.

6. Supplies Indexing. The indexing schema for finisher supplies is different than that used for marker supplies in the printer MIB and results in tables with complex (3 and 4) indexing. In the printer MIB, the marker supplies and marker colorant tables contain a reference index to the corresponding marker subunit, and therefore, those tables only needed two indices.

Ron recommended a similar scheme be incorporated in place of the current index scheme and

his proposal was accepted. Ron to document.

7. Finisher vs. Printer Inputs. The Finisher Supply Media Input Group appears to be an exact copy of the Printer Input Group. This stems from the fact that media supplies have dimension and names associated with them while most other supplies do not. The question was raised, 'Why can't we use the input group from the printer MIB for finishers too?' A simple cross reference table (AUGMENTing the Input table, for example) could be used to associate rows in the printer input table with specific finisher subunits. Another approach would be to state that finishers must always use a different hrDeviceIndex than printers. Then, it would be obvious which rows in the input table are associated with the finisher based on hrDeviceIndex.

Review of current Documentation

1. We reviewed the objects in the finSupplyTable and agreed that all are required.

2. We reviewed the objects in finSupplyMediaInputTable - Agreed to remove the following:

3. We agreed to add a "marker supplies" box to the printer model diagram.

Misc.

1. Correlation with IPP still needs to be addressed.