When PDFG ES2 converts Word documents, it extracts the metadata and compiles it as an XMP for the PDF.
There is a known problem however, when a file contains custom metadata: PDFG cannot compile the XMP properly for such files.
To check the metadata in the DOC, open Word.
Use the MS Office menu (the big round one, top left) : Prepare : Properties
A small yellow info bar will appear above the editing area.
In that area, Click “DIP Properties – …” and select “Advanced properties …”
Go to the “Custom” tab
If there are items in the space at the bottom labelled “Properties”, then your DOCX is likely to fail to convert.
There are two solutions to this:
1/ Log on to the LiveCycle Admin UI
2/ Go to Services : PDF generator : File type Settings : [your file type settings]
3/ Open Word file type settings
4/ Uncheck “Convert document info”
This will prevent PDFG from trying to extract and convert the Word metadata – thus excluding the problematic custom information
2) Obtain the patch
If you have an Adobe Platinum support agreement, you can contact technical support and request the patch.
There are a few ways of accessing an XDP in the LiveCycle Repository.
One of them is to specify a URI at project design time, in which case the URI will look like this:
However, if you want to specify the URL at run time, you would need to populate a variable.
The face of thge URL changes to:
$varname = “repository:///Applications/AppName/1.0/hierarchy/yourfile.xdp”
The server name and port remain specified in the Select Template dialog, under Runtime Repository.
With Central on Windows 2008, if you have multiple instances installed and start Central, some instances will fail to start quoting “open of table (….\JFXXX.TMP) failed”
The Central service in the Windows Services is started, but only some of the instances are running. No specific instance consistently starts or fails, it is random.
This is due to Windows TMP file creation APIs, which changed slightly in Windows 2008. For this reason, any version prior to Central 5.7 is likely to be affected on Windows 2008 (32 and 64 bit) when multiple instances are present.
A patch for Central 5.7 can be obtained from Adobe’s Enterprise Support – you can find their contact details from your Support Agreement.
Sometimes Internet Explorer (32-bit) will crash when using the Reader or Acrobat plug-in to display a PDF in a browser window.
The reason is that some third-party PDF creators use Acrobat’s DLLs, but rather than keep them in their own folders, copy them to system32/ which causes Acrobat to open defunct DLLs – and fall over as a consequence.
To resolve the issue, do the following:
Move the following files somewhere else (for example, create a folder C:\bad_dlls):
Of course, this means that whatever application installed those DLLs in system32 will stop working.
Identify it, and contact the software’s publisher to check if they have a solution.
If you’re feeling adventurous: You could tentatively open the Acrobat/Reader folder under Program Files\Adobe\Acrobat\Acrobat 9.0\ , and COPY the corresponding DLLs to system32 – but that is of the “dirty hack” class and would be generally disadvisable. The third party PDF application would not necessarily be able to use these DLLs anyway.