PDF to email friendly HTML

There is a service in LiveCycle to convert PDF files to HTML, and it the output looks pretty decent, but after looking at the html code, we realized that there were a bunch of DIVS and such that were added to the forms. This didn't work out to great as a solution for us, because we planned to place that html into an email, and with all the divs and such it would look horrible (since some email clients don't follow a standard). There were a few options in the service to try and manipulate the CSS and such, but nothing that gave a satisfactory result.


We noticed that when converting xdp to html, the best way to maintain structure was by using tables. Subforms convert to divs, however email clients do not always render divs properly, so we stuck to using tables to structure our forms and also to control the layout of our forms. However, the layout got messed up when we did the conversion, so the solution that we came up with was to use the renderHTMLForm service with the option of nostyles, and to add the styles in manually.
Essentially we noticed that all of the names of complex objects (objects containing other objects, ie subforms, tables, table rows) that we created in the form would be carried over into the created html, with some additions.

So if we have a table called Details, which was in a a subform called Content, it would be converted to a table with id=NContent_0.NDetails_0.

I'm not sure what the "N" denotes, but the 0 at the end is the index of the object, so if you have repeating elements, the index would be noted at the end.

At this point, ideally, we would have liked to user the renderHTMLForms to import a css file in to use,  but it puts the styles inbetween the head tags, which again is not great for email clients. So instead we wrote a custom component to insert it the styles from the css to inline (there are lots of libraries to convert css to inline, sorry wouldn't be able to tell you which).

The issue at this point was to know where to put the styles. Thats where the ids come in and why we used tables to structure the form. We were able to style the different parts of the form by placing them in the tags, matching them up with the appropriate id's. We used a config file to map the styles to the id's to try and automate and reuse as much as possible.

Not as elegant as i would like, but unfortunately the only way that i could think of to resolve the issue.

Importing a LiveCycle ES process into LiveCycle ES2

Back in july I had a blog posting about moving LiveCycle ES 8.2 processes to an ES2 environment, found here. Since then, Adobe has put up a new tool in their Labs that that will install as a plugin to Workbench. With this archive migration tool installed, LiveCycle Workbench ES2(SP1) users can import a LiveCycle 8.x archive into the Workbench workspace directly to take advantage of the new features available in ES2. A new LiveCycle ES2 application is created and all the resources in the 8.x archive are imported into the ES2 application.
The new tool can be found at http://labs.adobe.com/technologies/lcworkbench_archivemigration/

Digital Signatures and Rights management (part Deux)

If you have a form that contains a digital signature and has a policy applied to it, if you ever want to edit that signature (or form for that matter) you'll have problems, since the policy is protecting the form. What you'll need to do is use the "unlockPDF" service to temporarily unlock the form. You can only use this in a short lived process, so place that service and whatever you need to do to the form in a subprocess, and use that subprocess in your main process. At the end of the subprocess, the policy will be reapplied to the for automatically.

Another very important ote is that the security for the subprocess must be set to be invoked as a user that has access to the policy (so set the "invoke as" parameter as a specific user)*.

Note* I was have alot of problem with this, as I was getting the "No veiw permissions" error in my logs. The reason was due to the domain of my users. For some reason LC didn't like it, so once i recreated the users and policy into another domain, all became right with the world.

Digital Signatures and Rights management

I've just figured out that if you want to apply any type of policy onto a form (like thru a custom renderer) you need to apply the policy as the first thing. The reason being is that if you apply the policy afterwards, it breaks the digital signature.

Oddly enough this also applies if you reader extend the form. If you apply the reader extension THEN apply the policy, you'll get an error saying that you can't apply a policy on a signed form. Strange, eh?

Digital Signatures and Process Flows

Learning something new, when using digital signatures in a document, the data type of the form should be Document Form. This is exactly like an xfaForm, except you hve the ability to render the form just once and then once submitted the form as a whole document gets transferred over.

Read http://livecycleapps.wordpress.com/2009/02/11/livecycle-process-variable-cheat-sheet/ for more info

The only thing is trying to access field values of a document form type. I'll update when i have that figured out.

update* Looks like i'll have to use the export data service, then use xpath on that xml to access the different values. So you'd have to use something like this in the xpath;

/process_data/formVar//nameOfField

Its also helpful to get values from the form if you don't happen to have a schema attached.