Ask the LiveCycle Experts

One of the first things I want to make sure is clear is that a “static” PDF document can still provide interactive fields to a user that has downloaded a PDF and has opened it with the free Adobe Reader or Adobe Acrobat.  Calculations can occur and a great deal of interaction can take place between the user and the PDF form.  Although it can be, it is not limited to the constraints of a document that is simply downloaded and printed or simply viewed.  In the LiveCycle Designer world we typically call a non-interactive print & view document a “flat” PDF.

The difference lies with the actual look and feel of the form.  With a static form the fields of the form remain in the same position and look the same way.  The number of pages also remains the same.  If you opened PDF that had 30 fields and 5 pages, when you submit it electronically or print it out, it will still have 30 fields and 5 pages.  A dynamic form on the other hand, may have fields that change in number, appearance, size, color, any number of aspects.  Entire sections of the form can appear, disappear, or repeat any number of times.  The dynamic form you submit electronically or print out, may look entirely different from the document you started with.  A document with 30 fields and 5 pages may turn into a document with 10 fields and 1 page or 300 fields and 50 pages depending on the logic encoded into the form.

Where people usually run into difficulty and end up with a little less hair at the end of the day is with the “Save As” part of the Design process.  If you save a PDF form as an “Adobe Static PDF Form (*.pdf)” the appearance of the form will not change regardless of your code. Of course, if you save your form as an “Adobe Dynamic XML Form (*.pdf)” and there’s no code in your form that would cause it to change then it simply won’t change.

(Click Image to Enlarge)

To demonstrate the concept very simply (and without getting into subforms), take a look at these two samples.  Both are identical with the exception that one is “saved as” static and the other dynamic:

http://blogs.adobe.com/asktheexperts/files/20090914-just_a_simple_static_pdf.pdf

http://blogs.adobe.com/asktheexperts/files/20090914-just_a_simple_dynamic_pdf.pdf

You should notice that the check box of the static form does nothing while the check box on the dynamic form makes the “shipping” section of the form appear and disappear, dynamically changing the appearance of the form. The code that causes the change in appearance in the forms is identical.  You may also notice that the Acrobat debugger console (Ctrl-J from Acrobat) does not indicate any errors in the static form even though the code does not appear to be functioning correctly.  The JavaScript code in the exit event of “Name” that copies it’s value into the “Name” field below works well in both forms.

So, to share what will become a naturally occurring best practice when creating a new form: Immediately go to the properties of the PDF (right-click the Preview PDF tab) change the Default Language to JavaScript (under the Defaults tab), change the PDF Render Format to Dynamic XML Form and then finally, File – Save As an “Adobe Dynamic XML Form”.

We have no problems with a PDF form within Workspace when starting a process but when opening a new task assigned to a user we receive either the following 404 message inside Workspace or a message that says “Acrobat could not open ‘filename’ because it is either not a supported file type or because the file has been damaged…”.

How can we resolve this issue?

This usually occurs when you have a Document Form type variable in your process and in the Advanced Options of the variable you have selected the “Call the render service only once” checkbox.

While there are no issues associated directly with rendering only once, you need to ensure that you are passing a rendered PDF document to the next user in your process.  To ensure that this is the case, open your form template (the XDP associated to this variable) and look for a hidden button with the name “FSSUBMIT_”.  This hidden button is part of the Process Fields set of form fields you should have placed on your form initially.  By default the form will only submit the XML Data Package (XDP) of the form and not the PDF itself.

If the task assignment step in your process uses the Document Form type variable that is configured to only be rendered once then the user attempting to view the assigned task will not be able to view the PDF as it has not been properly rendered.

To correct this problem change the Submit As parameter of the “FSSUBMIT_” hidden button on your form to “PDF”.  This will ensure that the entire PDF itself is returned to your process and not just the data.  Once this is corrected, re-save your form and start your process again.  This will not correct any tasks that have already been assigned but new tasks should work well.

If you’d like to take a look at a working sample of this concept, feel free to download this sample.