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@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
kugler@us.ibm.com
Sent: 19 July 1999 23:22
To: ipp@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