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

[Steve G]

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.

 

[Andrew Thompson]

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.

 

[Steve G]

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.

 

[Matt Humphrey]

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 address removed) http://www.iviz.com/

 

[Roland de Ruiter]

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

 

[Oliver Wong]

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

 

[Steve G]

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.

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

 

[Steve G]

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.

 

[Eric Sosman]

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

 

[Patricia Shanahan]

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

 

[Matt Humphrey]

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 (e-mail address removed) http://www.iviz.com/

 

[Tarkin]

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.

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

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

 

[Patricia Shanahan]

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.

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

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

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