Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Internet web app - sending .PDF or .PS output direct to user printer

Reply
Thread Tools

Internet web app - sending .PDF or .PS output direct to user printer

 
 
Steve G
Guest
Posts: n/a
 
      08-04-2006
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.

 
Reply With Quote
 
 
 
 
Andrew Thompson
Guest
Posts: n/a
 
      08-04-2006
Steve G wrote:
....
> 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.

 
Reply With Quote
 
 
 
 
Steve G
Guest
Posts: n/a
 
      08-04-2006
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.
Andrew Thompson wrote:
> Steve G wrote:
> ...
> > 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.


 
Reply With Quote
 
Matt Humphrey
Guest
Posts: n/a
 
      08-04-2006

"Steve G" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.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
> 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.


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 http://www.velocityreviews.com/forums/(E-Mail Removed) http://www.iviz.com/


 
Reply With Quote
 
Roland de Ruiter
Guest
Posts: n/a
 
      08-04-2006
On 4-8-2006 18:40, Steve G wrote:
> Andrew Thompson wrote:
>> Steve G wrote:
>> ...
>>> 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.

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.]
--
Regards,

Roland
 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      08-04-2006

"Matt Humphrey" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
>
> "Steve G" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.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
>> 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.

>
> 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.


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

 
Reply With Quote
 
Steve G
Guest
Posts: n/a
 
      08-04-2006
>>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.

Roland de Ruiter wrote:
> On 4-8-2006 18:40, Steve G wrote:
> > Andrew Thompson wrote:
> >> Steve G wrote:
> >> ...
> >>> 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.

> 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.]
> --
> Regards,
>
> Roland


 
Reply With Quote
 
Steve G
Guest
Posts: n/a
 
      08-04-2006
>>>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.

Matt Humphrey wrote:
> "Steve G" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.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
> > 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.

>
> 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 (E-Mail Removed) http://www.iviz.com/


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-04-2006


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
> 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.


(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 ...

--
(E-Mail Removed)

 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      08-05-2006
Steve G wrote:
>>> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Direct standard output to printer. Doug Laidlaw Perl Misc 0 02-23-2007 03:00 AM
direct download of files vs web service app Patino ASP .Net Mobile 0 02-17-2007 07:01 PM
convert java web app 2 .NET web app =?Utf-8?B?bml6YW0=?= ASP .Net 0 02-28-2006 04:45 AM
Network printer: printer server vs direct network connection? alamoaudio@gmail.com Computer Support 3 09-20-2005 12:24 AM
Sending output to printer Carramba C Programming 2 02-15-2005 07:14 PM



Advertisments