Archive for June, 2010

LiveCycle ES2: Field spacing changes after conversion to Postscript with toPS2()


When you use the toPS2() method in LiveCycle ES2 to convert PDF files to PostScript, the spacing between fields is incorrect in the resulting PostScript files. In the examples below there are many differences,  for example the space following the last set of “nnn” characters is larger in the PostScript file than in the PDF file.

PDF file:

PostScript file:


This issue has been addressed in LiveCycle ES2 SP1 and later versions.

reference: (181434404/2553226)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycle ES2: Text-clipping at a page break in a complex table after conversion to Postscript with toPS2()


When you use the toPS2() method with LiveCyclce ES2 to convert PDF files that contain complex dynamic tables to PostScript, text may overlap in some table cells following a page break.

This issue has been reported with a table structure at the page break as follows:


 <data_field1>multi-line text</data_field1>
 <data_field2>multi-line text</data_field2>

The following image shows the table in Reader and after conversion to PostScript with ES2:


We have exposed a new flag in the XDP templates that can be used with LiveCycle ES2 SP1 and later versions.  Add the following line to the XML for all XDP templates that contain such tables:

<?originalXFAVersion LegacySplitPtCalcOverride:1 v2.8-layout:0?>

After using these flags in the XDP template and converting to Postscript again the table will appear correctly as follows:

Additional information

The calculation for the page-break placement pushes the data from the first subform also onto the second page, on top of the data for the second subform. When the data from data_field1 would normally fit on the first page, but the data from data_field2 causes a page break, then the data from data_field1 is pushed to the next page and rendered on top of data_field2.

reference: (181490290/2592355)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)

How to extract an MSI file from the EXE for Adobe Reader


Steps to extract the Adobe Reader MSI installation files from the compressed executable:

1. Obtain Adobe Reader from and save the file to your desktop.

2. Choose Start > Run.

3. In the Open text box, type: "%UserProfile%\Desktop\AdbeRdr80_en_US.exe" -nos_ne

4. Click OK.

5. When the Adobe Reader Setup screen clears, choose Start >  Run.

6. In the Open text box, type: %temp%

7. Drag the Adobe Reader folder to your desktop.

This folder contains AcroRead.msi and files needed for installation.

Update (thanks to the comment from V23 below)

For Adobe Reader X, the setup files will be extracted to a folder in:

  • %ProgramData%\Adobe\Setup (Windows Vista and above)
  • %ALLUSERSPROFILE%\Application Data\Adobe\Setup (Windows XP / Windows Server 2003)

If you wish to define where the files will be extracted, use the -nos_o switch as follows:

AdbeRdr1010_en_US.exe.exe -nos_o"C:\Folder" -nos_ne

Replace C:\Folder with the path to a local valid folder.  Please ensure the folder is empty as otherwise the existing files and folders may be overwritten/deleted.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.5/10 (27 votes cast)

LiveCycle ES2: renderPDFFormWithUsageRights() doesn’t respect locale settings


When you use the renderPDFFormWithUsageRights() method to render and reader-extend PDF documents, there are issues with the locale on the resulting PDF form.

For example, if you use this method to render XDP documents with German locale settings, then those settings are lost. Numeric fields are rendered using the default English locale. If you enter 4555 in a decimal field, it is displayed with the English locale 4,555.00, rather than 4.555,00 in the German locale.


In LiveCycle ES2 (, specify the default locale in the AdminUI under the Forms service Internationalization settings to handle all cases for your default language. For XDP templates that deviate from your default language, specify the language on the field/subform level in the XDP, or in the PDFRenderFormSpec setLocale() method.  These settings will then override the default locale.

Additional information

There are a few ways to define the locale for a form rendered through the Forms service in ES2.

  • AdminUI
  • PDFRenderFormSpec
  • XDP form-level
  • XDP field/subform level

The default locale for rendered forms is configured in the AdminUI under Home > Services > LiveCycle Forms ES2 > Internationalization. If  no locale is specified in the PDFRenderFormSpec in the API or render call, then the form is rendered in the default English locale.

Similarly, you can specify a default locale in the XDP form template with LiveCycle Designer. You can also specify the locale on a field/subform level within the XDP template by using “default” (which inherits the form-level locale). You can also explicitly define the locale in the field/subform properties.

LiveCycle ES2 ( ignores the form-level locale and respects the locale hierarchy as follows: field/subform, then PDFRenderFormSpec, then AdminUI.  This means that a locale (locale 1) specified on the field/subform level will override any different locales (locale 2) specified in the PDFRenderFormSpec and AdminUI. The individual field/subform will then be rendered in the final PDF with locale 1, and the rest of the form with locale 2. It is a product bug that the form-level locale is ignored.

In LiveCycle ES2 SP2 and later versions, Adobe has added add an “Auto” value to the PDFRenderFormSpec setLocale() method, which respects the XDP form-level locale. Then, the locale hierarchy is as follows: field/subform, then form-level, then PDFRenderFormSpec, then AdminUI.

reference: (181618235/2634790)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)