PDF Annotation Tools That Work Beyond Documentum 5.3

Over the years, a variety of software tools have become available for integrating PDF annotation functionality into the Documentum client suite.  Some of these tools include Brava!, AnnoDoc, Snowbound, and Documentum PDF Annotation Services.  Each product has its own feature set, but all provide the ability to mark up PDF documents and store the annotations alongside the document in the Documentum repository.  Each product has a client component that integrates with Documentum Webtop to provide the tools for adding markups to documents.  These client integrations utilize proprietary applets, Adobe Acrobat, or Adobe Reader with Extensions to provide this functionality.

Recently a manufacturing client requested help from TSG for replacing a legacy AnnoDoc system with another solution.  The most current release of AnnoDoc works with Documentum Webtop version 5.3, but the product does not support Webtop version 6+.  With Documentum 5.3 reaching end-of-life, the client was looking to upgrade to version 6.5, but an annotation solution needed to be found first.

Ideally, the client needed an annotation tool that could both read and update annotations made using the legacy AnnoDoc system, as well as provide the ability to create and save new annotations.  After some research, it was discovered that AnnoDoc and Documentum PDF Annotation Services use similar methods to store annotation files in the Documentum repository.  Both products store the annotation files as dm_note objects related to the original PDF document using the DM_ANNOTATE relation type.

While similar, there were still some challenges in getting Documentum PDF Annotation Services to open annotation files created with AnnoDoc.  AnnoDoc stores annotations in the Forms Data Format (FDF) while Documentum PDF Annotation Services stores them in the XML Forms Data Format (XFDF).  Although Documentum PDF Annotation Services is able to read FDF files, small changes needed to be made to the FDF files for the system to function properly.  Running a custom developed command line script to update the legacy FDF files proved to be a viable option for migrating the client from AnnoDoc to Documentum PDF Annotation Services.

TSG has recently made efforts to develop an annotation tool that will not require clients to have the full version of Adobe Acrobat to create annotations.  The tool is slated for integration with Documentum Webtop and OpenContent HPI.  Stay tuned to the TSG website for details on TSG’s OpenAnnotate product coming soon!

Working with Adobe Flex and iframes

As part of the upcoming Active Wizard 4.0 release, and as a result of a client’s requirement, we recently added a new input type: WYSIWYG. The WYSIWYG input type allows users to style and format text just like in a word processing application. After evaluating some of the popular HTML/JavaScript based editors we finally decided on FCKEditor (now CKEditor.) Another new feature of Active Wizard 4.0 is an Adobe Flex based Active Form component. Integrating these two new features proved to be quite the challenge.

At the end of the day, Flex is Flash; an HTML or JSP page will have a swf file embedded in it and the Flash Player plug-in will be used to render it. Until now, most of our Flex and Flash projects have consisted of either small components within a page, or the entire page itself. In both cases the default “wmode” parameter value has always been used: “window.” Integrating the WYSIWYG control within our Flex component required using a different wmode value: opaque.

In order to integrate the WYSIWYG control into our Flex component we had to use iframes and this is what necessitated the use of the opaque wmode value. A quick Google search for “Flex iframes” turns up quite an interesting selection. One of the top hits is a project on Google Code called flex-iframe. We actually wound up using this component as it’s quite robust and works well. However, the first hit is an article titled “Don’t Use IFrames for HTML in Flex” and lists reasons why using iframes and Flex/Flash is a bad idea. One of the reasons is specifically because it requires the use of the opaque wmode value and lists the following three reasons:

  1. Speed: There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load.
  2. Accessibility: wmode makes your movie invisible to screen readers
  3. Inconsistent Performance

At various points during development, issues 1 and 3 came up and were quite problematic. Regarding the speed issue, we noticed that the more complicated content an iframe contained the slower the performance was. Surely this could be expected to some degree, however, given that we were embedding complex JavaScript based WYSIWYG controls, our iframe content sometimes became all but unusable. Inconsistent performance also left us scratching our heads: two separate views that shared quite a bit of code wound up performing differently when their content was scrolled, but only in Internet Explorer. Fortunately, Adobe’s JIRA system already had that bug logged. Unfortunately the bug was still listed as open with no plans from Adobe to be fixed anytime soon.

So what did we end up doing? Several things:

  • To address the performance issue we wound up not embedding FCK in our form multiple times. Instead we embedded a simple html page that we updated when the user changed content. The WYSIWYG only appears when the user clicks in the html area, via a modal popup.
  • The scrolling issue fix was easy to implement, however, thinking of it took a bit of time. We initially tried some of the suggested fixes posted on the JIRA page, but they didn’t seem to work us. Since the issue only affected the UI while the user was scrolling the page, we decided to simply disable “live scrolling.” That is, the user can move the scrollbar normally but the rest of the UI won’t update until the user lets go of the scrollbar.

Flex  iFrames

In the end we wound up with a rather elegant solution that’s transparent to the end-user; they don’t know that they’re using a combination of Flash, HTML and JavaScript, it just works. While we hope Adobe eventually addresses the issue with wmode we would rather they create a better rich text editor (RTE.) We only went with the HTML/JavaScript RTE because the built-in Flex RTE wasn’t robust enough for our requirements. Had it been able to support superscript and subscript, copying and pasting from MS Word and the ability to output XHTML we would have gladly used it. While there are hacks to achieve some of those requirements, copy and pasting from MS Word doesn’t appear to be possible at this time. Hopefully Adobe will either enhance the built in RTE or offer official support for integrating HTML/JavaScript (via iframes or something else.) In the meantime all we can do is come up with creative solutions that work as best as possible given these limitations.

Adobe Livecycle PDF Workflow Automation

We recently had a client ask us to automate the conversion of PDF to PNG images as part of their business process.  Working with PDF files usually involves the time-intensive manual process of opening the PDF with Adobe Acrobat to make changes. Their process involved converting hundreds of PDF files into individual PNG images for each page, all within a few seconds of upload.  With Adobe Livecycle this entire process was automated without writing a single line of code.  Leveraging the Adobe Livecycle Enterprise Suite and the Adobe LiveCycle Workbench, we were able to map, design, develop, and test the entire solution in a very short time. An excerpt from the LiveCycle workflow can be seen below, which shows the logic of determining the orientation (portait or landscape) of the imported page, and the conversion to two separate sets of image sizes.

livecycleprocesslayoutzoom

Realizing this is only the beginning of what the Adobe Livecycle suite can do, we were also able to utilize the LiveCycle PDF Generator combined with the open source iText PDF manipulation library to automate the creation of a PDF file compiled from a variety of separate sources. The compiled PDF was generated from existing PDF files along with tabbed pages and inserts from their book layout system to create a complete book ready for printing.

The final piece of Livecycle utilized for this project was the PDF Generator IPP driver that allows a user to install a printer driver that they can print directly to from their favorite desktop applications. This lightweight PDF printer will generate the PDF on the Adobe LiveCycle Server and email the generated PDF to the user.

This is just the beginning of what Adobe LiveCycle can accomplish, and we are eager to explore more solutions that leverage LiveCycle. If you’d like more information about what we’re doing with Adobe LiveCycle, please feel free to comment or contact us.