Posts in Category "Output"

LiveCycle Output ES2: “Failure to automatically determine column ’5′ width”

Issue

If you are using LiveCycle Output to generate PDF documents using XDP files as input, you may encounter the following exception and no PDF will be returned:

0000012a XMLFormAgentW E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage
ALC-OUT-002-017: mid,tid: 29435,23593162.1 sev: f text: Failure to automatically determine column '8' width.
0000012a FormServerExc E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage
ALC-OUT-002-013: XMLFormFactory, PAexecute failure: "(com.adobe.document.xmlform.ReturnStatus@39133913)
Failure to automatically determine column '5' width."

If you load the same XDP file in Designer ES2 and goto PDF Preview, you may notice the same message as a warning in the log, but the PDF will be correctly rendered and displayed:

Failure to automatically determine column '5' width

Reason

This exception is occurring because of a problem in the Form design.  If you have a table in your form design with, let’s say 4 columns, you should check this table to ensure you don’t have a row with more than 4 fields defined.  This can occur especially when you have created the field objects first, and then converted a whole collection of objects into a table later on.  The extra (5th) field, can exist in a 4-column table if it has a width of “0″.

Here is an sample form to demonstrate the problem: support_test

Cell5 in Row1 is the extra field causing the problem in this case.

Solution

Simply delete the extra field as it is not visible anyway due to the “0″ width.

In future LiveCycle versions we will make changes in Output to return the PDF, and only show this message as a warning in the server log.  This will match the behaviour in Designer ES2 and Forms.

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

LiveCycle ES2: Relative images are missing after conversion to a flat PDF

Issue

If you are using the generatePDFOutput operation of the Output service to process a dynamic PDF document (i.e. to flatten it), you may notice that images referenced by relative paths are missing from the resulting flat PDF file.

This problem will be accompanied by exceptions in the server log similar to the following:

DataManager   E com.adobe.service.DataManagerImpl createFileDataBufferFromUrl TRAS0014I:
The following exception was logged javax.ejb.EJBException: An unexpected exception occured:
ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
    at com.adobe.repository.bindings.url.provider.RepositoryUrlDataProviderBean.getInputStream(RepositoryUrlDataProviderBean.java:249)
    at com.adobe.url.EJSLocalStatelessRepositoryUrlDataProvider_d16709f6.getInputStream(Unknown Source)
    at com.adobe.url.Util.openUrlStream(Util.java:105)
    at com.adobe.service.DataManagerImpl.createFileDataBufferFromUrl(DataManagerImpl.java:211)
    at com.adobe.service.DataManagerPOATie.createFileDataBufferFromUrl(DataManagerPOATie.java:54)
    at com.adobe.service.DataManagerPOA._invoke(DataManagerPOA.java:91)
...
Caused by: com.adobe.idp.dsc.DSCRuntimeException:
ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
    at com.adobe.repository.commands.RepositoryUrlDataProviderCommand.execute(RepositoryUrlDataProviderCommand.java:178)
    at com.adobe.repository.commands.CommandProcessor.execute(CommandProcessor.java:135)
    at com.adobe.repository.bindings.dsc.RepositoryProviderServiceImpl.repositoryUrlDataProvider(RepositoryProviderServiceImpl.java:674)
    ... 15 more
...
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-029-698: [495864]
    InvalidSourceException Exception on URL: repository:///orange_haus.jpg Exception: javax.ejb.EJBException: An unexpected exception occured:
    ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-016-649: [495864]
    Error attempting to read from file
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-029-461: [495864]
    XFAImageService: Image cannot be resolved for node: StaticImage1.

Reason

You may have rendered the PDF initially using the images referenced by relative paths (i.e. they were available at these relative locations on the server at render-time).  This image content is then stored in the PDF file for the initial page views.  Static PDF files do not re-render and therefore the image content already stored in the PDF remains valid, so the images are always displayed.  Dynamic PDF files can re-render later (where the relative paths to the images may no longer be valid), in which case Acrobat/LiveCycle will attempt to resolve the relative paths to the images again.

Acrobat can display the images without any problems, even if you force Acrobat to re-render the PDF document (by merging again with data).  Acrobat recognizes that the image is referenced by relative path, discovers it cannot resolve the path anymore, and therefore picks up the image content which is stored in the PDF already.

LiveCycle however does not handle this correctly.  This is a bug in the Output service for PDF  files with a target version > 8.0.  If the target version is < 8.0 then the images are retained.

Solution

This issue will be fixed in the next LiveCycle ES2 service pack (if there is one) and future versions (e.g. ES3).  There is a patch available for LiveCycle ES2 SP2 9.0.0.2 (XMF-2.204, FRM-2.202, OPT-2.201), so contact your LC support representative should you require this patch.

The solution exposes a new option “Use Following Resources from PDF” in the generatePDFOutput advanced settings.  If you set this option to “IMAGES”, it will include the image content from the PDF, rather than attempting to resolve the relative path.

reference: (182742389/2996897)

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

LiveCycle ES2: PDF form state not maintained after converting to PDF/a

Issue

 After converting a PDF file to PDF/A using LiveCycle ES2 you may notice that the form state has not been maintained for unsigned files.  This can manifest itself in that form objects (fields, buttons, subforms etc…) which were hidden in the original PDF file, are now visible in the resulting PDF/A file.

The form state is always maintained for signed files.

Solution

 This is an issue in LiveCycle ES2 (9.0.0.0, 9.0.0.1 and 9.0.0.2).  This issue will be addressed in ES2 SP3 and the new ADEP platform.  There are patches available for ES2 SP1 and SP2, so contact enterprise support if you require one of these patches.

Additional information

 We have added a new flag to the PDFOutputOptionsSpec used during the PDF to PDF/A conversion called “retainFormState“.  This flag must be set in the API parameters, or using the new option in the Workbench UI, to retain the form state on the resulting PDF/A file.

Here is the existing javadoc for PDFOutputOptionsSpec:

http://help.adobe.com/en_US/livecycle/9.0/programLC/javadoc/com/adobe/livecycle/output/client/PDFOutputOptionsSpec.html

reference: (182219821/2818751)

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

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

Issue

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:

Solution

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()

Issue

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:

<table_row>
 <left_table_cell>
 <data>text</data>
 </left_table_cell>

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

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

Solution

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 http://www.xfa.org/schema/xfa-template/2.4/ 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)

LiveCycle ES2: text-shifts after conversion to Postscript using toPS2()

Issue

When you use the toPS2() method in LiveCycle ES2 to convert PDF files to PostScript, some text-shifting occurs in the resulting Postscript file.

Here is an example where the text is shifted upwards and starts to overlap the border:

PDF file:

PostScript file:

Reason

A bug in how the server handles the field placement during conversion causes this issue, and can lead to data-loss in extreme circumstances.

Solution

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

reference: (181423968/2552257)

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

LiveCycle ES2: Checkbox marks changed after conversion to Postscript using toPS2()

Issue

When you use the toPS2() method from LiveCycle ES2 to convert PDF files to PostScript, checkbox marks are rendered differently in the resulting PostScript. For example, the checkbox marks are larger in the PostScript file than in the PDF file.

PDF file:

PostScript file:

Solution

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

Additional information

A bug in the rendering functionality during the PostScript conversion causes this error. This problem causes issues for customers who convert legally binding documents, and must guarantee that they haven’t changed since they were completed or signed.

reference: (181435838/2571942)

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