Form File Import/Conversion

(Windows Only)

DocOrigin is often used as a replacement for Adobe® LiveCycle™ Output, which is also referred to, correctly or incorrectly, as Adobe® or JetForm Central. While DocOrigin uses an open architecture with easily readable files, those other products use a proprietary binary file format.

DocOrigin Design's File > Open menu item allows you to select *.XATW files (of course), but also *.IFD (Adobe® Output Designer), *.XDP (Adobe® LiveCycle Designer), and *.PDF files. In the non-XATW cases, the "open" is actually an "import" in that the nominated form design file is instantly converted to an XATW as part of the file-open process.

Import Prerequisites

IFD and PDF conversion require, to the best of our knowledge, that the user have a licensed copy of one of:

• Adobe LiveCycle Designer version ES2, possibly ES4
• Adobe Acrobat Professional versions 8.1, 9, and X
• Adobe Experience Manager, possibly pre-version 11

The Adobe LiveCycle Designer contains utilities that convert IFD files to XDP format, and PDF files to XDP format. As the XDP file format is textual XML, such files are read directly by DocOrigin during its conversion process. You don't have to learn/use the LiveCycle Designer program. DocOrigin uses the needed utility silently, behind the scenes.

If you have installed Adobe LiveCycle Designer under C:\Program Files (x86)* (or D:\Program Files (x86) -- wherever Windows tells us the "special" Program Files (x86) folder is,) DocOrigin will find the needed utilities automatically. If you have installed it elsewhere you will need to change the following registry settings to point to the actual location of the utilities.

HKCU\Software\OF Software\DocOrigin\Design\FileLocations\ConvertIFDShell 
HKCU\Software\OF Software\DocOrigin\Design\FileLocations\FileLocations\ConvertPDF 

(Prior to 3.2.001.02)

HKCU\Software\OF Software\DocOrigin Design\3.1\Design\FileLocations\ConvertIFDShell 
HKCU\Software\OF Software\DocOrigin Design\3.1\Design\FileLocations\ConvertPDF) 

The above registry locations are used by Design. For the FormConvert non-GUI application (see Batch Conversion below) you can define the locations of the from-Adobe tools via the following environment variables: DO_IFD_CONVERT and DO_PDF_CONVERT.

Batch Conversion

DocOrigin supplies a non-GUI program called "FormConvert" which can be used to convert any of the above format files to XATW format. The same prerequisites apply for batch conversion as for conversion using DocOrigin Design.

Bumps in the Road

If you encounter errors during the conversion process, e.g. #5907, #5903, #1084, or 50463490, these are not DocOrigin errors but rather errors from the underlying Adobe tooling that we referred to above. If such a thing should occur, your installation of the Adobe products is probably not correct. We suggest that you:

1. Prove to yourself that you can open the IFD directly in Adobe Output Designer, and most preferably prove that you can compile it for a PDF presentment target. If you can't open it in Output Designer there seems little chance that Adobe LiveCycle Designer will be able to do its import operation. If you really can't open it in Adobe Output Designer, the best idea is to reinstall that product. Failing that please contact Adobe.
2. Prove to yourself that you can open the IFD with your installed Adobe LiveCycle Designer, whether that is from a standalone purchase, or from an install of Acrobat Professional 8.1, 9, or X. If you cannot open the IFD in Adobe LiveCycle Designer, then it is possibly because you have Adobe Output Designer installed under other than x:\Program Files (x86). Correct that. If that is not the case then, <sigh> re-install Adobe LiveCycle Designer. If the reinstall fails to help, please contact Adobe. If Adobe LiveCycle Designer cannot open the IFD then there is little hope for DocOrigin to open it since it relies on that Adobe tooling.
3. You could locate/verify that ConvertIFDShell.exe exists somewhere on your system, likely under your Program Files (x86) folder. If you can't find that you really must find and reinstall the Adobe software. If you do find it, you could attempt to do the conversion after you manually set the registry entries mentioned above to the location of where you found the .exe. This is somewhat grasping at straws since
   1. above should have worked. Please don't leap to the idea that only that one executable is needed. It must be surrounded by all the usual Adobe Output Designer files, configuration and whatnot. Those configuration files must certainly match those that you have been using in production.
   2. above applies to opening a PDF as well – except that there is no connection to Adobe Output Designer. And
   3. (desperation) applies except look for ConvertPDF.exe.
4. No, you cannot get an IFD out of an MDF. You must have an IFD for any form worth converting.

DO_SAVE_XDP

IFD and PDF files are not human-readable. They are "binary". The Adobe tooling does the much-appreciated task of producing an XML, human-readable (well, it's no literary thriller!), XDP file. It is that XDP file that DocOrigin reads and interprets. It can sometimes be handy, at least for SEs, to look at that intermediate XDP output that is used behind the scenes. By setting the environment variable DO_SAVE_XDP to some known file name, e.g. C:\Temp\LastConversion.xdp, you can always look at the latest intermediate XDP file as created by the Adobe tooling for importing a PDF or IFD.

Stepwise Conversion (optional)

DocOrigin uses background tooling from Adobe to get an XDP file and then reads that XDP file. If you wish, you could use Adobe LiveCycle Designer to import the IFD or PDF and save the XDP explicitly, completely separate from any DocOrigin involvement. Then you could have DocOrigin open (import) that XDP as a separate independent step.

Why mention that? Well, the Adobe tooling is not perfectly in sync. You may get slightly different results from using Adobe LiveCycle Designer itself versus from using the Adobe ConvertIFDShell, or ConvertPDF tooling. DocOrigin has no control over that. Converting your form designs from a binary, proprietary, format to an open, textual, format is precious, so having any alternative avenues is worth knowing about.

Conversion Effort Estimates

Ok, how long is a piece of string?

This is impossible to say. The actual import operation is mere seconds. But the results may need modification. Mostly it depends on whether the designer used only standard preamble or developed 'interesting' custom preamble. Also, the structure (or lack thereof) of the data can play a significant role in the conversion effort. If there is no natural correlation between the data structure (and even field names) with the structure and names used in the form design, then the effort will be greater. If the subforms are in a random jumbled order rather than a logical top-down sequence, another small effort will be required to shuffle the order of the panes into sensibility.

Most often, the bigger effort is simply to round up all of the needed collateral: the form designs, the relevant production configuration files, the images, sufficiently base-covering sample data (single page, multi-page, multi-documents), and corresponding expected outputs.

For conversion directly from PDF, the utility used will break up text strings any time there is a change in font (typeface, point size, plain/bold/italic). This then is what we have to work with. You may well wish to apply Design's Format-Combine Multiple Text Labels menu item.

Do also consider data conversion – of course, ConvertDatToXml Filter is handy in that regard.