 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2006Internet web app - sending .PDF or .PS output direct to user printer
I have a real brain-teaser here (it may not even be possible). We have a web app, it will run across the INTERnet (not intra). The app will generate reports. Currently what we do is: 1. generate the report (over on the server, obviously) as a .pdf file 2. once done, we forward the user to the URL of the .PDF file 3. Since IE knows what to do with filetype .PDF, he kicks off Adobe Reader and loads the .PDF in the new window. For non-technology-related reasons, we can't do it this way (the user must not be allowed to print the output more than once, and of course once we dump them into Adobe Reader they can hit the Print button all day, no way for us to stop them). So we need to figure out how to take this output (we're generating it with FOP) and dump it out to the user's printer (in other words, we don't display the file, thereby allowing them to print multiple times; we simply print it). I'm thinking with the code and the output file over on the app server, there really isn't a way for me to direct this output to the printer of a user who is running our app through IE. Or am I wrong? If I'm right, can anyone think of another way to achieve this result? Thanks as always. ... > For non-technology-related reasons, we can't do it this way (the user > must not be allowed to print the output more than once, and of course... ..as soon as I have a single hard copy of it, I can scan it and upload the scan to the internet.. Andrew T. the business process is more complex than that, so this is not an issue. We just need to prevent them from generating two original copies of the same generated .PDF file. > ... > > For non-technology-related reasons, we can't do it this way (the user [quoted text clipped - 4 lines] > > Andrew T. >> ... >>> For non-technology-related reasons, we can't do it this way (the user [quoted text clipped - 7 lines] > issue. We just need to prevent them from generating two original copies > of the same generated .PDF file. I have doubts about the feasibility of this. For instance the customer could have set up a printer queue which automatically prints several copies, or to several printers. And what should the customer do when his printer has a paper jam or runs out of ink: (must he/she go all the way and request for a new copy of the document? sounds like loosing your passport or drivers license). However, having said that you may want investigate more on the following items: 1) PDF allows you to secure your document; open a PDF file in Acrobat Reader and see menu File > Document Properties > Security. Maybe it can be setup to allow one copy only. Don't know how to define this in the PDF code, though. 2) Javascript document.print() allows to print a frame, maybe a hidden frame with the PDF document? 3) Use (signed) applet to print your document. 4) Create a custom application which allows to print a single copy of a file on that platform (ala AcroRead, but then AcroPrint for instance). Each customer has to install this application on his/her computer. Deliver your document from your appserver to the customer's browser with a custom extension and MIME type. The browser should trigger your application and print the document. [If you want your customer to have a single copy only, it's probably better to print the document yourself and send it to him/her by snail mail. Even then he/she could copy it on a high quality copier to make it look like a first print.]  SignatureRegards, Roland >>If you want your customer to have a single copy only, it's probably better to print the document yourself and send it to him/her by snail mail. Sadly, it has to be printed and in the customer's hands then and there, so it can be signed in real-time as part of the business process. > >> ... > >>> For non-technology-related reasons, we can't do it this way (the user [quoted text clipped - 34 lines] > mail. Even then he/she could copy it on a high quality copier to make it > look like a first print.] >>> If you want your customer to have a single copy only, it's probably > better to print the document yourself and send it to him/her by snail > mail. > > Sadly, it has to be printed and in the customer's hands then and there, > so it can be signed in real-time as part of the business process. Who gets to keep the signed copy? If the customer, they can make all sorts of copies afterwards, including scanning and editing out the signature to get a clean copy. If the customer does not get to keep the original, the whole process is broken. I try to get a copy of everything I sign. If I could not get a copy, you would not get a signature. Most business processes that require a signature are positively designed to generate a copy for the customer to keep. If you don't give the user access to the print dialog, to select the printer and set parameters, you could get into all sorts of difficulties such as printing on special paper. If you do give access to the print dialog, what stops the customer from increasing the number of copies, or doing a print to file? I have at least two installed "printers" that would give you problems. One is an "MS Publisher Imagesetter". Its idea of printing is to write a postscript file to disk. The other is "Print to FedEx Kinko's". It has an additional dialog, after the document appears to have been printed from the application's point of view, that asks, among other things, how many copies to print. That is the printer I would pick if I wanted 500 copies of your document. Patricia > >>If you want your customer to have a single copy only, it's probably > better to print the document yourself and send it to him/her by snail [quoted text clipped - 45 lines] > > > > Roland Shift the responsibility over to your legal department. Add verbage to the effect that there must only exist 1 copy of the document, singed by your end user, else thecontract/agreement/whatever is null, and you get to seize his business assets or some such measure (I'm joking, of course). You could look into digital signing ala the (US) Federal Government FAFSA pins. Good luck, Tarkin >>>> If you want your customer to have a single copy only, it's probably >> better to print the document yourself and send it to him/her by snail [quoted text clipped - 58 lines] > Good luck, > Tarkin The more the document looks like a contract, binding the customer to do, or not do, specified things, the less likely it is that it will get signed without multiple copies existing. For example, one copy needs to go to the customer's legal department for pre-signature approval. That copy will be retained, so that legal has a record of what they approved. Patricia >I have a real brain-teaser here (it may not even be possible). We have > a web app, it will run across the INTERnet (not intra). The app will [quoted text clipped - 17 lines] > am I wrong? If I'm right, can anyone think of another way to achieve > this result? Thanks as always. I'm going to assume for the moment that it's possible for your web app via it's returned page and a suitably privileged applet (including helper JNI or Active-X control) to directly invoke the user's printer, bypassing even the standard dialog box because it asks for the number of copies and can be controlled from console. Instead, let me ask how are you going to prevent the user from sticking the output into a copier? Although I realize that documents can be printed in such a way that they cannot be properly photocopied, I doubt that most users' printers produce such output. This also doesn't consider the very common cases where the printer jams or otherwise fails and the document must be reprinted. I'm asking this because I have seen too many cases where management has insisted on complex, draconian restrictions that are utterly worthless. I think the answer to your question is that it is possible using some very sophisticated companion technology and a great deal of trust on the part of the user, but that it seems pointless to do so. Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/ >>I have a real brain-teaser here (it may not even be possible). We have >> a web app, it will run across the INTERnet (not intra). The app will [quoted text clipped - 36 lines] > sophisticated companion technology and a great deal of trust on the part > of the user, but that it seems pointless to do so. I have a device driver on my computer which masquerades as a printer, but actually the output is stored in a file on my harddrive. I'd simply tell your webapp to print to my virtual printer, and I'd have an exact digital copy of the original document, which can be printed unlimited times. - Oliver >>>Instead, let me ask how are you going to prevent the user from sticking the output into a copier? I asked the same thing. Thankfully, that's a business-controls issue and not an app issue, so it's not our problem. > >I have a real brain-teaser here (it may not even be possible). We have > > a web app, it will run across the INTERnet (not intra). The app will [quoted text clipped - 38 lines] > > Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/ >>>>Instead, let me ask how are you going to prevent the user from sticking >>>>the > output into a copier? > > I asked the same thing. Thankfully, that's a business-controls issue > and not an app issue, so it's not our problem. Well, that's typical. On a standard (e.g. Windows / Unix / Sun) type machine you cannot control how or to where the user prints--the standard process has too many holes over which you have no control. You could engineer a non-standard process with custom printers, software and authentication management along the lines of http://www.acsac.org/sac-tac/wisac00/tue1330.abrams.pdf including custom ink and paper to make photocopying apparent, all of which would be incredibly expensive. Good luck with your project. Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/ Steve G wrote On 08/04/06 12:00,: > I have a real brain-teaser here (it may not even be possible). We have > a web app, it will run across the INTERnet (not intra). The app will [quoted text clipped - 17 lines] > am I wrong? If I'm right, can anyone think of another way to achieve > this result? Thanks as always. (Replying to the original because repeated top-posting intermixed with bottom-posting has made the follow-ups too difficult for my tired old brain to comprehend.) I think you're doomed. The closest you can come may be to use a special printer with cryptographic capabilities: You'd ship encrypted bits over the wire and forward them (still encrypted) to the printer, where they'd be decrypted just as close to the paper as your engineers can manage. Even then, a sufficiently determined user could try attaching probes to the outputs of the crypto device. If you need to let the users provide their own computers and their own printers, it is going to be impossible to assert complete control over the printing environment. It is a trivial matter to install a "printer" that prints to a file, from which the ordinary local print services can then make as many hard and soft copies as the user desires. You might write your own printer driver, something that prints only to a real physical printer and cannot be fooled into printing to a file. It'd use all the self-authentication techniques in the book to guard against tampering -- but even if it's sure the bits are going across an actual physical cable, it's never going to be sure they're being printed and forgotten rather than being recorded for later multiple playback. What are these documents you're printing? Money? Most national governments discourage free-lancing ... SignatureEric.Sosman@sun.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.