[cups.general] Canceling a job

[Johannes Meixner]

Hello,

I would like to discuss how to cancel a job because of
http://www.cups.org/str.php?L1675
and because of
http://lists.suse.com/archive/suse-linux-e/2006-May/1077.html
which is based upon Robert's perefect explanation in the
"Cancelling printing" thread on the Gimp-print-devel mailing list
(not yet available in the archives on sourceforge.net).

At the moment it should work as follows:

A)
If the backend gets its input data from a file
(i.e. when "raw" printing is done), canceling a job
would simply terminate the backend immediately.

B)
If the backend gets its input data from stdin,
canceling a job would leave the backend running
until it gets no more data from stdin because this way
the filter before the backend (i.e. the filter which
produces the printer specific data - i.e. the "driver")
can cleanly close off the data stream (and send appropriate
printer commands) to get the printer back into a clean state.

This is a reasonable default behaviour but it doesn't make sure
that canceling a job results a clean state in any case.

Case A) will never leave the printer in a clean state.
For example canceling a job on the CUPS system which is
printed from Windows via Samba using the Windows driver
(i.e. with "cups options = raw" in /etc/samba/smb.conf)
will never leave the printer in a clean state.

Case B) only leaves the printer in a clean state when it is
possible to somehow "reset" the printer while it is printing
for example in graphics mode and when the driver really does
the right clean-up stuff.
As far as I know most generic drivers (e.g. ljet4) don't do it.
I don't know if it is possible at all to "reset" those cheap
inkjet printers which don't understand a higher level printing
language.

Therefore it seems there cannot be one behaviour which works o.k.
in any case so that the canceling behaviour should be configurable.

As it depends on the particular printer, a default canceling behaviour
should be configurable for each queue (where the system fallback
behaviour is as described above).

As it depends how a job is printed ("raw" versus "filtered"),
it should be possible for the user to enforce a canceling behaviour
for each particular job (e.g. via an option for the "cancel" command).
The option for the "cancel" command is problematic because one
user could choose the "kill immediately" option which leaves
the printer in an unusable state for all other users.

As it depends on the particular driver, it may even make sense
to have a "*cupsCancelPolicy" in the PPD file which sets
the default canceling behaviour for a queue when the queue
is set up with this PPD file.

Or simply don't let us bother with this problem but let the user
choose for each job what works best for him via a section like:
-------------------------------------------------------------------
*OpenUI *CupsCancelPolicy/Canceling Policy: PickOne
*DefaultCupsCancelPolicy: Reset
*CupsCancelPolicy Reset/Reset printer: "Reset"
*CupsCancelPolicy Kill/Terminate immediately: "Kill"
*CloseUI: *CupsCancelPolicy
-------------------------------------------------------------------
Of course "Reset" would be only in a PPD when the associated
driver actually can do it.
The "let any user choose" seems to be problematic because with
"Terminate" one particular user can leave the printer in an
unusable state for all other users, but for the home user it may be
very nice to have this option available and an experienced printer
admin in business environment (can we assume those admins exist? ;-)
could easily change this section as he likes.


What do you think?


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/