Sometimes a person will develop a form and test it on their PC with Acrobat. When they are happy with the look, feel and functionality they will send it out to users. If the users have Reader then some of the functionality may not be available, leading to frustration.
LiveCycle Designer ES has a handy feature where the developer can set the target version of Acrobat/Reader and then check the warnings tab to verify that the form will work in that target version. However this does not take into account whether the form will be Reader Enabled.
The attached PDF does not present new information, merely gathers information on enabled features and restrictions together in one location. The information focuses on users who have the free Adobe Reader.
As I see it there are four possible options when deploying a form. The first considers when the users have Acrobat and the other three deal with Reader:
- All of the users will have Acrobat, so that the form does not need to be Reader Enabled. In this case there are no restrictions and the users will have full functionality;
- Where users have Reader and the form has not been Reader Enabled. This is the most restricted;
- When the form is Reader Enabled in Acrobat, users with Reader can save the form but they are still some features that are restricted. Note that certain license restrictions apply;
- The last option considers the form being Reader Enabled using LiveCycle Reader Extensions ES (or ES2). The degree of functionality will depend on the options selected by the developer during the process.
The sample outlines what users will be able to do and what restrictions apply depending on how the form is deployed.
This example does not contain any script, its just a reference document. It was created using InDesign and exported to PDF.
Screenshots showing the enabling process are shown when you hover over the question marks.
The summary is available here: Assure Dynamics LiveCycle Forms in Acrobat and Reader.