Here's a response from our printer expert:
There are customers who want to stop the printer without performing a physical
operation at the printer and they want to choose whether or not to NPRO.
In a "backspace 100 pages" scenario, for example, they want the printer to "back
up" and start printing the last 100 pages over again. Some customers want the
printer to stop and then start printing the last 100 pages immediately following
the previous pages (to save paper and time) whereas other customers want an NPRO
to follow what has already printed but before reprinting the last 100 pages
(because it provides clear separation at the backspace point which is more
important than saving money or a little NPRO time). In both scenarios, the
operator does not need to be at the console of the printer itself. All of the
control is done from the print server, not the printer.
If IPP does not support NPRO or does not support NPRO suppression, one of these
two customer scenarios can't be satisfied.
-Carl
"Anthony Porter" <anthony.porter at computer.org> on 07/27/99 02:31:05 AM
Please respond to anthony.porter at computer.org
To: "'Hastings, Tom N'" <hastings at cp10.es.xerox.com>,
anthony.porter at computer.org, Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
cc:
Subject: RE: IPP> OPS - Updated IPP Additional Admin operations notes and
agreement s [non-process-run-out as separate op]
Well, I am not sure that it makes sense to invoke NPRO remotely via IPP,
because it seems that the only times when one can imagine a case where an
operator might stop a machine without runout is when the operator is going
to do some physical operation on the machine, like adding paper or toner.
In that case, the operator is likely to stop the machine using the printer's
operators console, rather than using IPP.
As an example, you could imagine that a duplex printer with a stacker,
rather like a department photocopier, could benefit from NPRO, since it has
a long paper path, but I think that the only time you would stop the machine
without an NPRO would be to add paper, (or the machine would stop itself
when it runs out.)This is more of a temporary error condition than a pause
in the IPP sense.
If most machines do not support NPRO, then most clients will not support it
either. The clients will pause the printer after the current job without
asking for an NPRO even though they ought to. That makes it difficult for a
printer that does support NPRO. Should it do an automatic NPRO when pausing
after a job? You could say that NPRO is mandatory for clients. i.e that a
client must always check for NPRO capability, and invoke it if the printer
supports it, but I think that might be complicating the issue.
If IPP was the only interface between the operator and the printer, and the
printer had no buttons, lcd screens or whatever, then there would be a need
for an NPRO operation (along with a few others)
Anthony Porter
-----Original Message-----
From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Hastings,
Tom N
Sent: 26 July 1999 21:59
To: anthony.porter at computer.org; kugler at us.ibm.com; ipp at pwg.org
Subject: RE: IPP> OPS - Updated IPP Additional Admin operations notes
and agreement s [non-process-run-out as separate op]
However, it does seem that Carl's suggestion for making NPRO a separate
OPTIONAL operation makes sense, right, rather than making it an OPTIONAL
option on several other operations.
Perhaps, call it Runout-Printer (instead of Non-Process-Run-Out-Printer?
Tom
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter at computer.org]
Sent: Monday, July 26, 1999 02:02
To: kugler at us.ibm.com; ipp at pwg.org
Subject: RE: IPP> OPS - Updated IPP Additional Admin operations notes
and agreement s
Note that on the web (roll-fed) printers that I work with, I don't think
that it is possible to make NPRO an option. The printer tries to print jobs
continuously in order not to waste paper, but when it runs out of work or
has to be stopped for any reason, it has to run out the last job or the last
few sheets of the job will be ruined. Even if the last job before stopping
is cancelled, it is still run out, since leaving half processed sheets in
the printer can cause problems.
Another point is that for these types of printers, for safety reasons, the
operator has to be physically present to start and stop the machine and
would probably have to use some sort of console. I don't think that an IPP
interface for these machines should allow any direct start or stop.
There might be printers out there where NPRO could be a useful IPP option,
but I don't think that it is useful for large web printers.
Anthony Porter
-----Original Message-----
From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of
kugler at us.ibm.com
Sent: 19 July 1999 23:22
To: ipp at pwg.org
Subject: Re: IPP> OPS - Updated IPP Additional Admin operations notes
and agreement s
Tom wrote:
original article:http://www.egroups.com/group/ipp/?start=6011
> This updated document includes agreements reached at the 7/14/99 IPP
> telecon. I'll produce an updated version early next week for review
> at our 7/28/99 telecon.
I've finally managed to discuss these issues with someone here who is
actually clueful about printers. I will insert comments below.
...
>> ISSUE: What state the Printer comes back up on Restart-Printer and
> how can the client control?
>
We actually overload the "Enable" operation to do the equivalent of
Restart-Printer, so our printers always come up enabled -- and
typically would go right to 'printing' state.
> 16. ISSUE 6 (Shutdown-Printer operation) and ISSUE 11 (Pause-Job
> operation): The "synchronize" attribute: it is not clear why this
> would ever be false. Ok to get rid of from the Shutdown-Printer and
> Pause-Job operations?
"synchronize" is set to false in exceptional conditions; like when a
previous attempt to shutdown with "synchronize" 'true' hung (should
never happen but apparently it does sometimes). This could be
automated with some kind of timeout mechanism, but we chose to give the
operator direct control.
>> 17. ISSUE: It isn't clear which type of checkpointing is being
> suggested for synchronize: checkpoint a stream or checkpoint in a
job
> that is on a disk file in the printer.
For us it means checkpoint to disk. Get all the counters and whatever
from the output device and save that information persistently so that
the job might be resumed in future.
...
> 25. ISSUE 2: In the Reset-Printer operation, is the
"non-process-run-
> out" operation attribute really needed at all or can the default
> behavior for Reset-Printer be defined to be to perform non-process
> run out (for continuous and cut sheet printers)?
>> 26. ISSUE 3: In the Restart-Printer operation, is the "non-process-
> run-out" operation attribute really needed at all or can the default
> behavior for Restart-Printer be defined to be to perform non-process
> run out (for continuous and cut sheet printers)?
>> 27. ISSUE 4: In the Space-Printer operation, is the
"non-process-run-
> out" operation attribute really needed at all or can the default
> behavior for Space-Printer be defined to be to perform non-process
> run out (for continuous and cut sheet printers)?
>> 28. ISSUE 5: Is the Shutdown-Printer operation, it the "non-process-
> run-out" operation attribute really needed at all or can the default
> behavior for Shutdown-Printer be defined to be to perform
non-process
> run out (for continuous and cut sheet printers)?
These are all similar questions which I will try to give a general
answer to. It turns out that on some of our printers,
"non-process-run-out" (NPRO) is an expensive thing to do. It wastes a
LOT of paper, and runs up click charges.
Perhaps the cleanest resolution to these issues would be to make NPRO a
separate operation rather than an operation attribute.
BTW, we don't support NPRO on our cut sheet printers.
>> 29. ISSUE 7: On Shutdown-Printer with "when" = 'now', is the current
> job automatically restarted when the Printer is restarted? Or does
> some client have to issue a Restart-Job operation?
In our implementation, the Job that was current at Shutdown-Printer
time is in 'paused' state when Printer is restarted. It must be
manually resumed.
>> 30. ISSUE 8: On Cancel-Current-Job, why isn't non-process-run-out
> automatic on a continuous form printer? When would an operator want
> to cancel the job and NOT run out the last sheets.? It would be
> simpler to require process-run-out when canceling the current job
> (for continuous and cut sheet printers).
Again, waste of a lot of paper. In fact, this operation is the one
least likely to want NPRO, since the canceled job is presumably trash
anyway.
>> 31. ISSUE 10: For the Pause-Job operation, is the "non-process-run-
> out" operation attribute really needed at all or can the default
> behavior for Pause-Job be defined to be to perform non-process run
> out (for continuous and cut sheet printers)?
>
Again, I propose making NPRO a separate extension operation.
-Carl