Join Tim Huff and Jonathan Bowman as they walk you through the process of using Acrobat Pro and the free Adobe Reader for collaboration.

They will show you how your entire team can create, view, and respond to comments. You will learn how to see the comments that are being made allowing you to streamline your reviews and approvals (and everyone just gets along!).

Points that will be covered:

• Get everyone on the same page to help build consensus and make better decisions faster
• Bring together all the necessary content for a project in a single organized file
• Use familiar commenting tools to share feedback and respond to one another's comments
• Include virtually anyone in your shared reviews using free Adobe Reader® software (version 8 or later)
• Quickly resolve issues by synchronizing screen views as you walk someone through your document in real time
• Minimize confusion between revisions by highlighting the differences in text and images when comparing PDF files

Click here to register

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.

If you add a Paper Forms Barcode object to a fill-and-print PDF form using either Designer or Acrobat and the value of the barcode will change while opened within the free Adobe Reader then the PDF form you are distributing needs to be licensed with an Adobe® LiveCycle® Barcoded Forms ES license.

Here are a couple of scenario's that may help you understand this concept further:

Scenario 1:

• A PDF Form with a dynamic 2D barcode (also known as the Paper Forms Barcode) is filled-in and printed with Adobe Acrobat Standard or Adobe Acrobat Professional
• The user of the PDF form changes a field value that causes the value of the barcode to change
• The 2D barcode is not compressed
• An Adobe® LiveCycle® Barcoded Forms ES license is not required as the 2D barcodes printed by Adobe Acrobat Standard or Adobe Acrobat Professional are not encrypted or hidden and can be read by a barcode decoder capable of reading 2D barcodes.
  

Scenario 2:

• A PDF Form with a dynamic 2D barcode is filled-in and printed with the Free Adobe Reader
• The user of the PDF form changes a form value that causes the value of the barcode to change
• The 2D barcode is not compressed
• An Adobe® LiveCycle® Barcoded Forms ES license is required or the 2D barcode printed by the free Adobe Reader will be encrypted* (Reader 7.x) or hidden (Reader 8.x and higher) and cannot be decoded by any barcode decoder

*Take note that the encryption mechanism used in Reader 7.x is not a "feature" that can be turned on or off.  It is a licensing mechanism only.  Encrypted barcodes cannot be read by the Adobe Decoder.

Scenario 3:

• A PDF form with a dynamic 2D barcode is filled-in and printed with Adobe Acrobat Standard or Adobe Acrobat Professional
• The 2D barcode is compressed
• An Adobe® LiveCycle® Barcoded Forms ES license is not required
• Only the Adobe® LiveCycle® Barcoded Forms ES Decoder license is required to decode the compressed 2D barcode
• The barcode is FLATE compressed so a software based decoder could be modified to decode the FLATE compression if required.

Scenario 4:

• A PDF Form with a dynamic 2D barcode is filled-in and printed with the Free Adobe Reader
• The user of the form changes a form value but there are no changes to the value of the barcode
• The 2D barcode is not compressed
• An Adobe® LiveCycle® Barcoded Forms ES license is not required and the 2D barcode printed by the free Adobe Reader will can be read by a barcode decoder

If you are still not sure of the concept, take a look at these samples and be certain you test your forms with the free Adobe Reader prior to distributing them to ensure that they have been properly licensed.

This first sample only contains "//" in the form1.#subform[0].PaperFormsBarcode1::calculate - (JavaScript, client) event and this.rawValue="123456789101112131415"; in the form1.#subform[0].PaperFormsBarcode1::initialize - (JavaScript, client) event.  The barcode value will not change at runtime and if printed using the free Adobe Reader, the Barcode will still render correctly.

adobe_livecycle_barcoded_forms_no_license_initialize_only

This sample has not been properly licensed and the barcode contains the default auto-generated script to include all contents of the PDF form at runtime.  Because the form is not licensed properly and the barcode value changes at runtime the barcode will either encrypt itself in Reader 7.x or become hidden in Reader 8.x or higher.

adobe_livecycle_barcoded_forms_no_license_changes