Posts in Category "Questions"

Adding a Formatted Value in a Barcode


When users enter a date into a form field that displays as MM/DD/YYYY the data encoded into the 2D barcode appears as YYYY-MM-DD.  How can I ensure data is encoded in the right format?

The automatically generated script that includes fields in a 2D barcode uses the “node.value” which will capture the XML formatted value.  In the Calculate code you’ll see this as “fieldValues.push(node.value);”. To use the formatted values you can remark out the original code and replace it with:


This will use the formatted values you provided in the Validation Pattern.


Enhanced Security Documentation


We have a number of external-facing PDF forms that use Web Services to populate certain aspects of their data.  I understand that 9.3 has Enhanced Security turned on by default.  What’s the fastest way we can get communication working with our servers?

Joel Geraci covers this topic in an existing blog article here but the two documents you will need to get started are:

Enhanced Security Troubleshooting Guide and FAQ
Link directly to Workflow fixes with enhanced security enabled page

These should provide you with the direction you’re looking for.

However, if you are in a situation that needs a quick fix and completely open access then you could deploy a totally-open master policy on the root directory of your server as a starting point and then work through your forms, Reader Extensions certificate, and sub-directories to ensure you implement a secure solution.

<?xml version=”1.0″ ?>


<site-control permitted-cross-domain-policies=”master-only” />

<allow-access-from domain=”*” />

<allow-http-request-headers-from domain=”*” headers=”*” />


If you would like to just use a master policy then I would suggest associating the policy to your Reader Extensions certificate.  This would allow only PDF forms extended with your certificate to access services on your server.


CIFS and Versioning


I want to enable CIFS on my Content Services implementation but am wondering if overwriting files via CIFS will remove the metadata of the original file?

Overwriting files via CIFS (Common Internet File System) using Windows Explorer, for example, will not remove any of the metadata that was previously entered via the web interface.  The description and aspects will be kept intact.  Additionally, if you have versioning enabled (aspect “Versionable”) another version of the document will be created.  Advanced features like check in & check out can also be enabled via CIFS providing users the ability to work independent of the web interface.

When enabling CIFS I would suggest that you create a rule that allows a “librarian” either physical or virtual to track content that is being uploaded via CIFS to ensure the proper metadata is eventually entered via the web interface or by an automated mechanism that extracts data from your forms and pushes that data into the metadata of the document where it may be visible in the web interface.

The Difference Between Static and Dynamic


I am new to PDF development with Adobe LiveCycle Designer ES and do not understand the difference in the terminology between a “static” PDF and a “dynamic” PDF.  Isn’t a “static” PDF just a regular PDF that is downloaded and printed?

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:

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”.

HTTP Status 404 when Opening Task


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?


HTTP Status 404 - type Status report message description The requested resource () is not available.  Apache Tomcat/5.5
Acrobat could not open 'filename' because it is either not a supported file type or because the file has been damaged...


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.

Adobe LiveCycle Barcoded Forms Licensing


When do I need to license
Adobe® LiveCycle® Barcoded Forms ES software?

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.



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.