Job hold and release using printer's own hardware

[bse]

>
> > CUPS implements job hold and release, of course, such that a print job =
> held by the CUPS server can be released from a web browser or =
> specialised application running on a PC (either a desktop or a =
> small-board computer) or even a user's iPhone or iPod Touch (!) etc next =
> to the printer. (Except that the iPhone etc don't do Kerberos, which we =
> use for CUPS authentication.) A second method of job hold and release =
> would be for the printing system to send the job to a Multi-Function =
> Device (MFD) - i.e. printer/copier etc - marked in such a way that the =
> MFD itself will hold the job until the user releases it via the front =
> panel.
> >=20
> > I think that the first method - implemented, I've been told, for =
> instance, by http://www.pykota.com/ - is probably superior (one can move =
> the job to and release it at any printer), but (as far as I know) it =
> does require extra hardware to be dedicated to each printer.
> >=20

I myself am looking into this, and i think that the simplest, cheapest and most flexible solution is to use a small netbook (~150-200 USD) as a release station. Do not try to use the printers functions.
This approach also makes it possible to have the copy function controlled by for example PyKota.

There was a message some time ago from someone working on this on a school. he was trying to implement 'show all MY jobs' in the CUPS webpage. Anyone heard anythin about that?

> > Is there a solution which permits held CUPS jobs to be released using =
> a printer's own hardware? Is either the first or the second method above =
> thus possible? Clearly 'Yes' (first method), for a printer which had a =
> front-panel web browser (which system required users to authenticate for =
> the CUPS server), but what if, like us, you have Ricoh MFDs and may end =
> up with HP MFDs? (There are some smaller HP printers with integrated - =
> limited? - web browsers, I gather, but I doubt that these 'speak' =
> Kerberos.)
> >=20
>
> I think that one part of the problem is the proprietary interfaces which =
> are on the printers and copiers. This means you are not able to change =
> them without the assistance of the copier manufactures. Maybe there are =
> printers out there which are not using a proprietary interface, but I =
> have not yet seen one.=20
>
> In addition, different manufactures, seem to have a different approaches =
> to communication and control or printer functions and job control via =
> the network. I have yet to see copier with anything more than a web =
> based interface for job control via the network. Again, there could be =
> something out there which is offering something more with which I am not =
> familiar.
>
> A standardized network based communication and control system for =
> printers/copiers would be great. Such as system would allow for is CUPS =
> to communicate with the printer(s) and to release the job(s).
>
> There is some traction in this area by individual copier / printer =
> companies. However, it is very slow and requires the at least one major =
> company to get in and support / work on an open standard and =
> implementation of this standard.
>
>
> ----------------------------------
> This email is protected by LBackup
> http://www.lbackup.org
>
>
>