Harry Lewis - IBM Printing Systems
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/20/97=
09:08 AM
---------------------------
Harry Lewis
11/19/97 10:23 PM
To: jmp@pwg.org @ Internet
cc:
From: Harry Lewis/Boulder/IBM @ IBMUS
Subject: Re: JMP> Job MIB doesn't handle Uncollated Copies
There hasn't been a whole lot of discussion regarding my proposal (belo=
w) other
than Ron indicating he believes it should be accepted.
I would like to modify it slightly, in a manner which I believe better
accomplishes the goal of distinguishing between collated and uncollated=
copies
yet results in fewer changes to the Mib.
To put it as simply as I can, I propose to add
currentCopyNumber
currentDocumentNumber
copyType
and to keep
sheetsCompletedCurrentCopy
impressionsCompletedCurrentCopy
documentCopiesCompleted
jobCopiesCompleted
The example flows the same as before:
For a 3 impression job with a request for 3 copies.
Uncollated 3/3 (copyType =3D External Collation)
--------------
sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber
--------------- -------------------------- -----------------
1 1 1
2 1 2
3 1 3
4 2 1
5 2 2
6 2 3
7 3 1
8 3 2
9 3 3
Collated 3/3 (copyType =3D Internal Collation)
------------
sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber
--------------- -------------------------- -----------------
1 1 1
2 2 1
3 3 1
4 1 2
5 2 2
6 3 2
7 1 3
8 2 3
9 3 3
The reason for the change from currentSheetNumber and currentImpressonN=
umber is
that there may be several sheets in the paper path, (different) impress=
ions may
be ripping and printing at the same time etc. It's very hard to say whi=
ch is
the "currentImpression" or "currentSheet" but easier to say which is th=
e
current copy. It is easy to say which sheet has just completed (stacked=
).
Note that, while drivers should protect from this, it is theoretically =
possible
to mix collated and uncollated copies (try it with your favorite printe=
r...
it's fun!). At this point, attributes like current copy really break do=
wn. We
feel, rather then try and define even more attributes to handle this
pathological case we should just say behavior of the MIB, at this point=
, is
device specific.
Harry Lewis - IBM Printing Systems
jmp-owner@pwg.org on 11/14/97 11:31:38 PM
To: jmp@pwg.org
cc: hastings@cp10.es.xerox.com, rbergma@dpc.com, bpenteco@boi.hp.com,
jkm@underscore.com
Subject: JMP> Job MIB doesn't handle Uncollated Copies
This message could be long - suffice it to say that I hope this news wi=
ll be
received in the spirit of an "early warning" interoperability issue.
The issue lies with the following Job MIB attributes:
|sheetsCompletedCurrentCopy(152)
|impressionsCompletedCurrentCopy attributes(113)
|documentCopiesCompleted(93)
|jobCopiesCompleted(91)
The problem is that these attributes can accurately reflect a "Mopy"
or internal collation, but are inadequate if used to describe
uncollated copies (or externally collated... such as use of
sequential output bins).
With "Internal Collation", one copy is "worked on" at a time. That copy=
is finished (jobCopiesCompleted) and the next is started, resetting
"sheetsCompletedCurrentCopy"
With "External Collation" (uncollated) multiple copies are "worked on"
before any copy is completed. Thus, "sheetsCompletedCurrentCopy" has
no meaning and "jobCopiesCompleted" jumps from initial to final value
in one increment (not very useful).
One possible reaction to the realization is to catagorize "External
Collation" as uninteresting, or just a "larger" job. (I had this
tendancy, initially). But, recall, IPP supports collated and
uncollated copies. Also, as mentioned above, the uncollated case is
the same (to the Job MIB agent) as sorting into multiple outputs.
I have discussed this problem, at length, with my development team and
also consulted with Tom Hastings (editor), briefly. Tom was receptive
and helpful and contributed to the following proposal:
Add the following attributes
--- currentSheetNumber currentImpressionNumber currentCopyNumber currentDocumentNumberReplace these "completed" attributes with their new "current" counterpa= rts ------- sheetsCompletedCurrentCopy(152) impressionsCompletedCurrentCopy attributes(113)
Decide whether or not to Keep these "completed" attributes ---- documentCopiesCompleted(93) jobCopiesCompleted(91)
for accounting purposes. Note, the "completed" values ONLY make sense for collated copies and/or FINAL values on uncollated jobs. For this reason, we recommend adding a final additional attribute --- copyType (ENUM - Internal Collation External Collation)
The value of the currentXxx attributes is 0 while the job is PENDING. The values increment to 1 as the first impression is produced. An abbreviated example (sheets and jobs, only) should help visualize. For example, assume a 3 impression job with a request for 3 copies.
Uncollated 3/3 (copyType =3D External Collation) --------------
sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 1 2 3 1 3 4 2 1 5 2 2 6 2 3 7 3 1 8 3 2 9 3 3
Collated 3/3 (copyType =3D Internal Collation) ------------
sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 2 1 3 3 1 4 1 2 5 2 2 6 3 2 7 1 3 8 2 3 9 3 3
The issue of whether or not to keep attributes
documentCopiesCompleted(93) jobCopiesCompleted(91)
could be resolved by specifying that the final value of
currentCopyNumber currentDocumentNumber
*is* the completed value and the attribute maintains this value for the remainig life of the entry.
I did not show an example using currentDocumentNumber because this is for high end implementations that collate documents within jobs. Nonetheless, the same problem (solution) exists.
Harry Lewis
=