Going round in circles on this one. Way back last year I suggested a mobile printing solution that essentially had students printing to a pdf file and uploading the pdf file for later printing. The idea of using pdf rather than postscript was to get round the problem of students having to install a generic postscript driver and configure it.
It was a fair solution and that bears some work. The scenario is that the student uploads the pdf file to their workspace and then has to login to a web based application to select the file and queue it for printing, file conversion being enabled by running pdf2ps and queueing it as a print job.
However the landscape has changed between then and now. What is required is a mobile printing solution that will interwork with whatever print/quota management solution is deployed.
The crude solution is quite simple. We create an lpd holding queue as a generic postscript queue and users spool to it. Messy and users need to authenticate in some way, meaning that its probably not on given the diversity of operating systems out there. However the idea is attaractive - users then log in to a web application, authenticate again, and then select the job they want to print, which is passed to the backend print system. Lpd is not a good solution as it doesn't do authentication. IPP does and in fact we would use ipp based printing with authentication. However installing an ipp printer needs having to distribute a print driver, or have users configure a printer locally. To make the call of the complexity or otherwise of doing this have a look at this example from a US university.
We could combine the ideas into something more elegant. Users still need to generate pdf files, which probably means windows users installing CutePDF (or using open office to export to pdf).
Once the user has generated the files they then open a connection and login to a web app.
They are presented with a list of files and an option to print them now.
They also get an option to (a) upload a file to print later (b) print a file now.
Option (a) puts the file in the spool space for printing later.
Option (b) takes the pdf file and spools it with pdf2ps to a printer. Users can also get an option as to which printer to print to. The print job is handed over to the backend print system, users print quota debited and so on.
Advantages:
- Users can upload and print the files from anywhere
- Users can upload but defer printing of files until they are ready to print
- Users only need to login to the print management application once
Disadvantages
- Users need to create pdf files
- Printing is not seamless - users need to login to print management application
If we go for an ipp only solution:
Disadvantages
- Users need to install and configure remote printer
- Users need to login to separate print management application to release print job
- User do not have the option of immediate print
Advantages
- Printing is seamless
And yes we probably could offer both options in some wierd combination ...
2 comments:
Uniprint is a commercial solution that is also built around the 'convert to pdf' trick to give universal printing without knowledge of the target printer
The implementation plan is as follows:
+deploy linux vm with cups printing to virtual queue wth ldap authentication
+provide a simple web based app to allow release of job to pharos
+provide a ipp aware universal driver to users
+provide a job to clean out unprinted jobs on a daily basis+
and from there scale out to provide the 'upload and queue' option for pdf files, and possible an option to email in to print pdf files.
Files could be stored in a ~/.printfiles directory in users own dedicated filestore.
Post a Comment