When adding an ImageField to a form it’s a common requirement to allow a user to remove the image. By default clicking on the image field will only let the user replace it with another image. If you want to remove it altogether then this little piece of code attached to a button will help:
imageField.rawValue = null;
When LiveCycle became ADEP Document Services all of the existing modules were ported over but I thought it would be useful to revisit them all and see what as new. This post gives a summary of the modules which are available to any Document Services solution (excluding the foundation services which come with all Document Services modules) and should be familiar to those who have worked with LiveCycle ES1/ES2 in the past.
I’ve been doing a piece of work for a customer who wanted a simple form distributed around their organisation for staff to fill in and return. The only additional requirement was that end users need to be able to save the document whilst filling it in. Most of my work to date has been using the Adobe LiveCycle product suite and so I naturally turned to Reader Extensions ES2 which would give end users the ability to save documents offline but comes at a rather large premium in terms of licence costs.
A recent project required me to write a custom component to merge image data with some text. This was simple enough in itself but testing the output Base64 image data with PDF files proved a pain. As a result I made a very simple PDF in Designer which allows you to test your Base64 encoded image strings to see how they’ll look in a PDF document. The following link will let you download the form which can be opened in designer. The archive also contains a very basic data schema and test data to get you started. Just replace the Base64 string in the “sampleData.xml” file with your own string. Fire up Designer and click the Preview tab to see if the image is displaying properly.
Here’s another gotcha when using LiveCycle Output ES2 that’s had me stumped for a few hours. I designed a form which used a number of fragments which tested fine within designer. Once deployed to the server I was always getting blank forms. A quick check of the logs revealed the following warning:
ALC-OUT-002-058: Cannot retrieve the resource from Repository Path.
A bit of digging around and I hit the a knowledge base article on Adobe’s site. Basically there’s a “limitation” with the way the form is compiled which means relative paths within fragments and XDPs can cause problems. The solution is to turn the relative path references (which are inserted by default in Designer) into absolute paths. Doing this sorted the problem for me but this is something that needs fixing!