When configuring LiveCycle you can enter a directory where fonts are stored and can be used by LiveCycle. If this directory is not valid when calling XMLForm it can result in the error code {3}.

You can modify the location of the font directories in the administration console under Settings > Core System Settings > Configurations. You will need to restart the application server after modifying these settings.

If you have recently applied Solaris 10 Update 10 XMLForm may start failing with error code {3}. There is a compatibility issue between the compiler settings that Adobe uses to compile the XMLFormService and some additions that Oracle have made to Solaris to support GNU extensions to their ELF symbol versioning. What this means is that Solaris no longer recognizes XMLFormService as a valid executable and will not run it.

The best solution here is to update Solaris to a more recent version that contains the fix. Details on exact versions can be attained from Oracle.

A workaround is to disable the run-time linker check by removing the DT_VERSYM entry from the objects dynamic section in libstdc++.so.6.

To apply the workaround you should run the following command on the libstdc++.so.6 file found in ServicesNatives2/lib directory:

In this situation you will most likely see the following exception also in the server log:

CSIServerRIBa W JSAS0638E: [com.ibm.org.omg.CORBA._ObjectStub.signalStringValue] Client authentication required at the server but no principal information is present in the <server>:<port> method request from client {2}.

We have seen this issue occur when strict global security was turned on in WebSphere and the clientcertificateauthentication for the csiv2inbound property in the WebSphere configuration was set to “Required” instead of “Supported”, and when the transport was set to “SSLRequired” instead of “SSLSupported”. Change these to “Supported”, as shown below, to resolve this issue.

If you are using LiveCycle Forms ES to render complex XFA forms as PDF and the forms contain subforms/tables which can split over multiple pages, you may notice some text-overlapping following a page break as follows:

Solution

You can use some processing instructions in the XDP template to control how the page break affects the field content. There are 2 processing instructions that can be used in this case to fix the text-overlapping issue, so that the contents no longer overlap the field boundaries:

<?layout allowDissonantSplits 1?> <?layout allowJaggedRowSplits 1?>

You should add these PI’s to your XDP templates only if you are encountering the issue described above. You can test these PI’s in LiveCycle Designer ES by using the PDF Preview tab.

By adding these PI’s the text-overlapping is resolved and appears as follows on the rendered PDF form:

The values in pop-up menus change when you move between pages on an XHTML form rendered from an XDP template with LiveCycle Forms ES. Some drop-down lists (DDLs) show the empty value, whereas others actually have a different entry from the original value.

This behavior is not expected, as the drop-down lists are marked as read-only. This issue is serious, as it affects data integrity in the submitted forms. You can test this behavior using FormsIVS in LiveCycle ES with the NoScriptXHTML transformation.

Solution

Adobe has resolved this issue in LiveCycle ES 8.2.1.4 and 10. There is a patch available for LiveCycle ES 8.0.1, so contact enterprise support if you require this patch in your environment.

This warning is an informational message from the repository cache and can be ignored. In the ADEP platform (ES3) Adobe will downgrade this warning to an INFO or FINE level message, so it doesn’t appear in the logs.

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.

Solution

In LiveCycle ES2 (9.0.0.0), 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 (9.0.0.0) 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.

The AdobeFnt11.lst file is created by the XMLForm process when CoolType is started and the fonts are enumerated. The file is used when generating PDF, Postscript, PCL and ZPL output to find the correct fonts for the document content.

If you have added a font and it is not being picked up you can force an update on the file by stopping the XMLForm process (e.g. manually in task manager), deleting the file and then restarting the XMLForm service (e.g. by re-starting the original document generation/conversion process). The AdobeFnt11.lst file will be recreated with all of the new fonts added. Normally you don’t have to do this, as the new font should be located and added automatically.

PDFMM also uses this file, as it deals with PDF files, which also use fonts.

If you would like to control which fonts should be embedded in the final PDF when rendered using LiveCycle Forms ES, then please follow the steps below.

Reason

This could be a common requirement if you are producing PDF documents for multiple environments:

the internal environment, where the user’s systems have all of the fonts available already

the external environment, where you would need the additional fonts to be embedded

At render-time, you know which environment is making the call, but do not know how to control the fonts which are getting embedded.

Solution

The XCI file, or XCI options string in FormsIVS, is what controls the render options used by Forms. To control what fonts are embedded, you must create your own custom XCI file, and pass that as a parameter to the renderPDFForm method, or as an option to FormsIVS. There are two options which you can use in the XCI file to control what fonts get embedded (alwaysEmbed), or what fonts do not get embedded (neverEmbed).

1. Copy the default pa.xci file and create a custom.xci file (for the purposes of this example, we will assume you create the custom.xci file on the root of the D drive)

2. Set the value for alwaysEmbed/neverEmbed as follows in the custom.xci file:

<fontInfo>

<alwaysEmbed>[fontName1],[fontName2]</alwaysEmbed>
...

</fontInfo>

3. Call the renderPDFForm method setting the XCIURI property, or FormsIVS with the following parameter in the options String:

&XCIURI=file://D/custom.xci

or on some platforms:

&XCIURI=D/custom.xci

By editing the custom.xci file manually you will be able to generate PDF files controlling the fonts which are embedded. You could generate multiple XCI files for various environments and just call the respective XCI file to use for each document.

If you are using FormServer 7.1 you may want to disable client-side caching. This will prevent previously entered values from appearing on a new form when you open it in a fresh browser instance.

Reason

The problem is that Acrobat/Reader is caching the form (along with its data). It does this based on the URL address (same URL = same form/data). Unfortunately, since this is a client setting there is no easy way to disable it.

Solution

Here are some suggestions to achieve this:

1) on the form (i.e. will be on a form by form basis):

add this code into the form:ready event -

var oDoc = event.target; oDoc.nocache = true;

2) make the URL unique:

An easy way of doing this is to return a date/time stamp as an unused parameter in the URL. This can be easily added by either the JSP or the servlet. For example:

This exception is caused by accented characters in the XMP metadata. Removing the accented characters will allow the importXMP() to complete successfully, so there is obviously a problem with the encoding.

Solution

You may be using the following code to generate the data:

lvFileW.write(sb.toString().getBytes());

To resolve the issue you must set the encoding to UTF-8 if there are accented characters: