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

Discussion in 'Java' started by Steve G, Aug 4, 2006.

  1. Steve G

    Steve G Guest

    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.
    Steve G, Aug 4, 2006
    #1
    1. Advertising

  2. 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.
    Andrew Thompson, Aug 4, 2006
    #2
    1. Advertising

  3. Steve G

    Steve G Guest

    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.
    Steve G, Aug 4, 2006
    #3
  4. "Steve G" <> wrote in message
    news:...
    >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.iviz.com/
    Matt Humphrey, Aug 4, 2006
    #4
  5. Re: Internet web app - sending .PDF or .PS output direct to userprinter

    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
    Roland de Ruiter, Aug 4, 2006
    #5
  6. Steve G

    Oliver Wong Guest

    "Matt Humphrey" <> wrote in message
    news:...
    >
    > "Steve G" <> wrote in message
    > news:...
    >>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
    Oliver Wong, Aug 4, 2006
    #6
  7. Steve G

    Steve G Guest

    >>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
    Steve G, Aug 4, 2006
    #7
  8. Steve G

    Steve G Guest

    >>>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" <> wrote in message
    > news:...
    > >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.iviz.com/
    Steve G, Aug 4, 2006
    #8
  9. Steve G

    Eric Sosman Guest

    Re: Internet web app - sending .PDF or .PS output direct to userprinter

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

    --
    Eric Sosman, Aug 4, 2006
    #9
  10. Re: Internet web app - sending .PDF or .PS output direct to userprinter

    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
    Patricia Shanahan, Aug 5, 2006
    #10
  11. "Steve G" <> wrote in message
    news:...
    >>>>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 http://www.iviz.com/
    Matt Humphrey, Aug 5, 2006
    #11
  12. Steve G

    Tarkin Guest

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


    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
    Tarkin, Aug 6, 2006
    #12
  13. Re: Internet web app - sending .PDF or .PS output direct to userprinter

    Tarkin wrote:
    > 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.
    >>
    >> 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

    >
    > 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
    Patricia Shanahan, Aug 6, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Samuel Lee
    Replies:
    0
    Views:
    500
    Samuel Lee
    Nov 11, 2003
  2. =?Utf-8?B?VGFuaw==?=
    Replies:
    1
    Views:
    6,114
    srinivasgajula.mca
    Apr 27, 2010
  3. Carramba

    Sending output to printer

    Carramba, Feb 15, 2005, in forum: C Programming
    Replies:
    2
    Views:
    315
    David Resnick
    Feb 15, 2005
  4. Replies:
    5
    Views:
    131
  5. Doug Laidlaw

    Direct standard output to printer.

    Doug Laidlaw, Feb 23, 2007, in forum: Perl Misc
    Replies:
    0
    Views:
    82
    Doug Laidlaw
    Feb 23, 2007
Loading...

Share This Page