To know more, read Sudhanshu Singh's blog post on the LiveCycle blog.
To know more, read Sudhanshu Singh's blog post on the LiveCycle blog.
There is a confusion about what features of Acrobat and PDFs in general offer by way of securing documents. I would like to do a very cursory overview of the items that I have so far seen users consider “security.”
To be clear, by “security” I mean the ability or inability to access the contents of the PDF, thus safeguarding information from entering the wrong hands.
1) Not Security-Oriented
Unlike on your Dollar, Euro or Pound notes (etc), the watermark is NOT a guarantee of integrity, veracity or anything at all.
In the PDF world, a visible watermark only exists as a notification mechanism. If a watermark says “Confidential,” it is only warning the viewer that the content is confidential, but will not otherwise try to make itself indelible.
It is meant to be a very visible mark on the page, with the added property of not completely obfuscation the items underneath (allowing readability to be maintained)
A Certified PDF carries a digital signature certifying that certain things can and cannot be done with it. Namely:
-A PDF certified to run privileged scripts can run scripts requiring special privileges, such as writing to the hard drive.
-A PDF certified to be unmodified means that so long as the PDF has been modified withing given parameters (fields filled in for example), then the certification will hold. If a visual aspect of the PDF changes though, the certification will be broken, and Acrobat will report an error.
Certification covers a number of other use cases as well, but I hope the above illustrates sufficiently why this is a not a security-related item, rather a usability concern.
c) Reader Extensions Usage Rights
Acrobat and LiveCycle can extend the usability of PDFs to Adobe Reader, the free PDF viewing application. By extending usability features, you can allow Reader users to fill in forms and save that content, add comment annotation, and other functionality.
However, if the same extended form is opened in Acrobat, the user can do to the PDF pretty much anything that Acrobat has at its disposition.
REUR adds functionality to Reader. Any extra functionality it does not add is a restriction that Reader already had.
a) Password Protection
Using password protection, you can encrypt the PDF so it can only be opened by a person who has the password. You can also prevent the PDF from being used in certain ways, such as modifying the pages.
You cannot however track who has opened the PDF, when and at what IP. That is the domain of Rights Management.
b) LiveCycle Rights Management (aka Policy Server)
LiveCycle 7 introduced Policy Server, later renamed to LiveCycle Rights Management. Adobe LiveCycle/ADEP Rights Management protects your documents from being accessed by parties you have not authorized to do so.
This allows the document publisher to:
-protect with a user ID/password combination
-force the identification to go to a remote server
-restrict usage rights depending on the user’s group
Read the full article at http://blogs.adobe.com/an_tai/archives/176.
I’ve been doing a piece of work for a customer who wanted a simple form distributed around their organisation for staff to fill in and return. The only additional requirement was that end users need to be able to save the document whilst filling it in. Most of my work to date has been using the Adobe LiveCycle product suite and so I naturally turned to Reader Extensions ES2 which would give end users the ability to save documents offline but comes at a rather large premium in terms of licence costs.
I’d always ignored Acrobat as I’d never needed to use it’s standalone functionality but something about the simplicity of this requirement made me look again. Sure enough since a few versions ago Acrobat now has a form of Reader Extension capability. Form designers can use Acrobat (or Designer) to create their form and distribute it via Acrobat and reader extend it (note to Adobe: make this easier to find in Acrobat X Pro, currently it’s hidden under the “Save As” file menu for some reason).
This all seemed a little too easy and instantly made me want to find some sort of limitation as otherwise Reader Extensions ES2 would look a very expensive option compared to the relative inexpense of purchasing Acrobat X Pro licences. I eventually turned to the EULA, searching for some sort of “gotcha” for this feature. Sure enough there is one (section 16.8.3).
A recent project required me to write a custom component to merge image data with some text. This was simple enough in itself but testing the output Base64 image data with PDF files proved a pain. As a result I made a very simple PDF in Designer which allows you to test your Base64 encoded image strings to see how they’ll look in a PDF document. The following link will let you download the form which can be opened in designer. The archive also contains a very basic data schema and test data to get you started. Just replace the Base64 string in the “sampleData.xml” file with your own string. Fire up Designer and click the Preview tab to see if the image is displaying properly.
Original article at http://michaelsteward.com/2011/09/16/displaying-base64-images-in-designer/.
I’m starting a new hands on series for LiveCycle called appropriately: Hands On LiveCycle. This series will give you a complete and working sample LCA (LiveCycle Archive) file that you can import and run on your LiveCycle server. These hands on entries will attempt to solve a real world problem and will start out simple and continue to grow in complexity. If you have a suggestion for a hands on entry you would like to see feel free to let me know!
I’m kicking the series off with a problem that something that most consumers and agencies can relate to. How to handle a form that requires a wet signature, or an actual physical signature on the document.
In a perfect world everyone would accept a digital signature and all forms would be able to be submitted online. However, we don’t live in a perfect world and a good number of companies and government agencies still require a wet signature on a document or form to do business. If you wanted to fill out a form for a financial service or a government request the typical process today might go something like this:
- Download the document
- Print the document
- Fill out the document
- Sign the document
- Mail the document
Once the document is in the mail the process continues:
- Receive the document
- Key in the data in the document to the database
- Store the document on the server
There are quite a few things that can go wrong with this human centric process. The document could get lost in the mail, the user could fat finger the data, causing delays, or the document could be stored in the wrong place. There are several ways that this process can be improved, just by using LiveCycle Reader Extensions, the LiveCycle Foundation Services and the free Adobe Reader (Barcoded Forms is now included with the LiveCycle Reader Extensions service) Using LiveCycle Reader Extensions allows you to automate several pieces of this process and in some cases more, depending on how a company or agency is willing to accept the form.
For this LiveCycle Hands On, it is assumed that the document will be filled out, printed, signed and mailed in by the applicant. Once the document arrives at the agency, it will be scanned and placed in a folder that is watched by LiveCycle. Once LiveCycle sees the document in the folder it will be processed, the applicant data will be stored in a database and the document will be written to the file system.
This process could be made even faster by removing the snail mail portion if the agency was willing to accept a document by email. If so, the applicant could scan the document themselves, attach it to an email and send it to an email address that LiveCycle monitors. Also, with the use of Reader Extensions, the user can now save a copy of the completed form to their hard drive.
Download the zip file: Barcoded_Form_Demo.zip
The zip file for this hands on has a .lca file containing a form, some sample data and a process as well as a sample filled out form and a SQL script to create the demo table. The SQL Script should be run on the server that is hosting the LiveCycle Database and should use the adobe schema. The form will work either as the PDF file included, or if the form is printed out and scanned. LiveCycle is able to decode the information from the barcode either way.
The Barcoded Form Demo Process:
The process is broken down below into steps and the operations used.
- LiveCycle recieves a document from the watched folder to start the process
- LiveCycle extracts the data from the barcode and adds it to a XML variable. Operation: Decode Category: Barcoded Forms
- LiveCycle extracts the XML form data from the barcode data and stores it in an XML list variable. Category: Extract To XML Service: Barcoded Forms
- LiveCycle sets the form data to the first element of the XML list variable. Operation: Set Value Category: Foundation
- LiveCycle inserts the data into the database. Operation: Execute SQL Statement Category: Foundation
- LiveCycle writes the document to the file system. Operation: Write Document Category: Foundation
Please feel free to ask any questions in the comments and I will try to answer them as quickly as I can!
Original article at http://www.underprise.com/2011/05/20/using-reader-extensions-and-barcoded-forms/.
Lately I have had a request from a customer of mine who wanted to modify existing XDP forms (ie. change a label or a field value) on the fly without going in LiveCycle Designer (ie. the procedure would imply costs for hiring the dev department).
His idea was to have a Form A, in which he would be able to specify the changes he desires to have in the Form B, submit the form A to a LC orchestration which would apply the changes and render the Form B back in Acrobat/Reader or even the browser plugin.
Here I am only covering the call to LC and the rendering back to the client.
Note: I am using LCES 2 SP2 (126.96.36.199) running on Jboss.
So we have Form A that could look like this:
As we can see we have a few fields that would mean something to Form B and as an end user we will open Form A in Acrobat/ Reader or even the browser plugin to enter the value we want to see in Form B.
We need to go in LC Workbench to create an orchestration which will render Form B:
We can find the right URL for the call by selecting the Default startpoint properties:
Since I going to run the test on the same machine where Livecycle is running the URL looks like this:
Note: “test” is the name of my application and “renderForm” is my process (orchestration) and 1.0 is its version.
This is the URL I put in the submit button in Form A (see first screenshot).
In order to make the call successful, we need to create variables to match the fields in Form A: Name, FormContent and MainParagraph.
Of course, in the scenario where you want to modify Form B with Form A fields values, you would need those variables to apply the desired changes.
Note: by matching i meant the variables name and type (most of the time it would be string but you can have list as well).
Here I am only rendering the Form B without any changes so I did not bother adding more activities in my orchestration which would utilise those variables.
Once the orchestration and the forms have been saved and the application deployed on the server, all we need is to open Form A in the client of our choice, here I used Internet Explorer so we can see the URL at the top.
I click on the button “open form via REST” and the login request pops up and i use my LC credentials to access:
Once logged in Form B is appearing in the same window:
Note: When using Reader or Acrobat, it will open a new window for Form B.
No need to Reader Extend Form A to make it work hence it works in Reader standalone and plugin.
Original article at http://blogs.adobe.com/ADEP/2011/08/invoke_forms_from_xdp.html.
Original article at http://technoracle.blogspot.com/2011/03/government-20-architectural-patterns.html.
1- using the attachments tab
I have included the PDF which allows the user to add attachment , view the attachment and deleted the selected attachment from the form.
Please click here to access the formPDF Form
PS- THIS WILL ONLY WORK WHEN YOU OPEN THE FORM WITH ACROBAT.IF YOU WANT IT TO WORK IN READER YOU WILL NEED TO APPLY USAGE RIGHTS USING THE READER EXTENSIONS ON THE SERVER
Original article at http://eslifeline.wordpress.com/2009/04/06/adding-attachments-to-pdf-form/.
– Drew Brazil
With LiveCycle Designer you can create interactive PDF forms. Interactive PDF forms are useful for gathering information from recipients who want to complete and submit the form online, as well as print a copy of the form.
Below is a link to a comprehensive tutorial written by Samartha Vashishtha, which explains how to create and distribute an interactive form. This tutorial discusses how to create the form, key consideration to keep in mind while creating the form, how to distribute the form, how to manage responses, and how to use scripting for conditional fields.
The tutorial also includes a link to a sample form, which you can view as you follow along.
For more information, see http://ewh.ieee.org/soc/pcs/index.php?q=node/1879
Original article at http://blogs.adobe.com/livecycledocs/2011/01/tutorial-designing-interactive-pdf-forms.html.