Hi there,
There might be some holes in the business case or my understanding of it (but without knowing all the details this is only an observation) .... Not sure what the differentiator between the electronic and printed version is .... that is in essence they are both just copies after it has been digitally signed. I realize that the online version can detect any changes made after the signature and show a change in status since signed where as someone could just use a tool to duplicate (whatever the document is and is meant to represent) the document and print out a fake. But even with a non-electronic solution and a wet ink signature at some point you need to trust a paper copy as being an original. So if they are not using some sort of embossing stamp on paper copies why the need to specifically stamp it 'copy'? If they are using an embossing stamp to represent an original then could you not just watermark the electronic right from the start and hence any printed version will contain the word 'copy' and any original hardcopy is requested from the issuer and has the embossing stamp?
That observation aside, based on what is in the original post you could do a
few things each with potential challenges depending on the software and architecture you have...
1) Code on the form
If the assumption that once this document is signed it becomes official holds valid; then this will work because if not signed then clicking print will trigger the watermark. In this case, as soon as you sign it you will not get the watermark when printed, but of course you can print as many copies as you like.
To do this put code on the pre-print event that will turn a hidden read-only field (containing the "COPY" watermark) visible. This way when viewing online it is never watermarked and when viewing the printed copy it is always watermarked (you can put code behind the PrePrint event of the top level node in your form that will make a field's presence visible. That field at design time would have no caption / set to readOnly / have the default value by what you want the watermark to say / have its presence set to hidden and then you would just use code like <fieldname>.presence = "visible".
2) Using Policies
Use two policies (because the dynamic watermark is based on a policy and cannot be assigned based on user/group in one policy)
a) So you will be sure to policy protect the document prior to signing with one of the policies (assume the “user-watermarked”). The challenge here is that the individuals who approve will also need the ability to switch the policy (policy set admin permission) so they can use the Rights Management end-user web interface to switch to the “approver – nonwatermarked” policy and do whatever it is that makes it an original and then switch back to the "user-watermarked" policy.
Note: What if while the policy is switched the regular user wants access and now can't get it or that the approved user even remembers to switch the policy back. Another options is…
b) Automate it based on the full requirements == something like
i. Capture who is authenticating to an automated LC Process.
ii. If it is a regular user then the process grabs the already completed/signed and protected PDF from a repository and records the licenseId of the protected documenet while passing the doc back to the user.
iii. It is also possible that if in the future an approver is requested to generate a valid printed copy then when they authenticate it grabs the (user-watermarked) protected/signed PDF from the repository and switches the policy to the approver-nonwatermarked policy and passes that doc back to the approver who can print the document.
iv. It is also possible that you could do a bunch of other things such as
i. Auto switch back the policy to the user-watermarked after the approver prints by capturing the print event
ii. Instead of above you could make printing part of the process if the approver doesn’t actually modify and resign the document. That is get the protected/signed doc from repository > switch the policy > send to a printer > switch the policy back.
iii. If for some reason the approver actually has to make changes to the document then although protected with the same policy you now have two documents. the one originally sent to the user and the one the approver wants to change and print as an original. In this case you could have that same process retrieve the licenseId of the original policy protected document distributed to the user and revoke it.
Hope those ideas will help you take your detailed understanding of the use case and apply some or all of the suggestions.
