What we still need to do is provide a means for people using their own machines to upload and print but making it as simple as possible for the user. Making it simple means it can't be seamless as we need to make as few assumptions about the user's machine and browser as possible. So here's the cartoon:
- User logs in to system
- System presents the user with a web page listing the user's files and an option to do an http upload of a file (analogy is the geocities website manager)
- Besides each non-pdf file we have two options - convert to pdf and print. All printing is done by converting to pdf and then pdftops, with conversion being done with either OpenOffice command line mode or abiword command line mode as appropriate and then print/export to produce the pdf. The analogy is with Zoho's or Google Doc's print and import options
- Pdf files have an option view or print, this means that users can check the layout before printing
- Printing is done by passing the print job through pdftops and then queing it to a holding queue with lprng.
We then have a second web based print release application that can be accessed either separately or as a flow on from the web based printing solution. This application basically allows the user to requeue the print job from the holding queue to an active queue or delete the job. An added refinement would be to add an estimate for the number of pages and hence an estimate of the cost to print.
It's not elegant but it does allow users a way to print from any device with some local store and a browser.
1 comment:
IPP might appear to offer an alternative, but we have the problem of having to remotely install printer drivers onto the users machine.
This can be fraught with difficulty to say the least. The idea behind this whole exercise is to have the user have to do as little as possible
Post a Comment