Form(ing) Standards - Recycling Old Stuff Can Be Incredibly Painful
I am on my favorite soapbox - “standards” – standards around form filling
By: Clinton Jones
Apr. 20, 2012 08:00 AM
I am on my favorite soapbox - "standards" - standards around form filling. Generally speaking, no discussion of standards could be complete without an assessment of the state of play of the not so humble Adobe Portable Document Format or as most of us know it, PDF. I debated the merits of the PDF back in the late 1990s (an astonishing 14 years ago) and with the passage of time, a few things have changed but in some respects they are the same.
The reason this topic is quite focal for me at the moment, is the fact that I continue to see customers and prospects take a hard line in wanting to retain their existing PDF documents and at the same time, make them more technically relevant to the continuing trend of trying to eliminate paper forms and improve back office efficiency by avoiding the need for people to laboriously transcribe data from electronic forms into application screens of key record keeping systems like SAP ERP. This is an area where Winshuttle has made some significant in-roads in helping customers eliminate transcription from Excel and InfoPath into back office ERP systems through an integration layer built around the Microsoft product suite.
Adobe has been around since the early 1980s and the idea of PDF was to create a document format that wouldn't require special processing by the computer, and could be viewed and printed regardless of the installed OS - first version was released in 1993. At the time there was the Macintosh, OS/2 from IBM, DOS and early versions of Windows.
By the mid 1990s, PDF documents were pretty ubiquitous for electronic documents. You needed a reader, which you could often get off a Bulletin Board or bundled with some of the many distributable software packages available at the time. A frustration experienced by many continued to be the fact that Microsoft didn't natively support generating PDF documents from spreadsheets, presentations and Word, and was fighting on several document writing fronts, including against the languishing WordPerfect. Microsoft did however have Envoy, a program that allowed a reader to read Microsoft Office documents; the availability of this product meant that partners and customers that did not use Microsoft products could still view Microsoft documents. In 2000, Microsoft released an initial version of an XML-based version of Excel which it incorporated into OfficeXP, later in 2002 Word followed and when Office2003 was released Office open XML was pretty much standard.
Adobe took a little longer than Microsoft to embrace some degree of openness and it was only in 2001 that the PDF specification was opened up for use. Officially, in 2008, it was released as an open standard. But, as Joel Geraci points out on Quora, an Acrobat 1.0 PDF still renders 100% correctly on Acrobat X, more than 15 years later.
This bit of history is important to understand why PDF has been so successful. Consider that despite our relative resistance to generating paper copies of documents, when we do need to reduce an electronic document to a hard copy, it needs to be pretty much pixel perfect. We want the images to appear where they should, we want the fields to line up vertically and we want the pagination to appear at the correct break points in the document. The combination of printers, supported font faces, paper sizes and margins can result in some very interesting outcomes and this too has driven the improvements in products like Microsoft Word to allow a true WYSIWYG experience. Of course, I try to discourage printing as much as possible and then find myself very frustrated when I discover that the idle printer at home won't print anything because the ink cartridge is as parched as the Gobi desert or the rollers on the laser printer have become as hard as rocks and won't pick up the paper. The visual experience is nonetheless important, especially for form filling.
Some great perspectives on the pros and cons outlined by Quick PDF are:
Returning to my problem or frustration of the moment, I looked at the form that was presented to me recently and tried to figure out just how much effort was going to be involved in manipulating this document to work with a Winshuttle Web Service connecting it to SAP. As the support partner at another company stated, "The challenge we have with PDF forms is that the form filling functionality of PDF is much more advanced than the form creation capability of MS Office. So for us to replicate a PDF form in MS Office, we need to work with imperfect tools to do so. It is essentially like trying to edit an image that has been created with Adobe Photoshop with Microsoft Paint. The advanced tools in one program are just not available in the other."
There had been some hopes that we could simply do a like conversion of PDF content to MS Office formats, however, when a PDF form is converted to MS Office format, some features (i.e. table lines, boxes, etc) get converted as graphics, which sometimes makes it difficult to edit freely as you would with a simple text document. Most automation conversion software cannot produce "fillable" forms per se. So don't pin any high hopes on PDF to MS Office converters.
The tricky thing with PDF forms is that they require quite a bit of work sometimes, depending on the nature and complexity of the form.
At face value, the task should have been fairly straightforward. The problem we concluded is that the method used to build the Adobe PDF form doesn't conform to any of the contemporary interactive form standards either for PDF or for MS Office. In addition, one of the characteristics that I discovered emerging in another installation is a seemingly random approach to naming technical objects. Developers have an uncanny ability to come up with some of the most curious names imaginable for technical objects, and although some of them are very descriptive, if there is missing information in either the name or in the documentation of the technical object then supporting them at some later stage will prove to be troublesome especially if the initial developer has moved on to another assignment.
My conclusions? If you're determined to recycle an existing Adobe form, make sure that it is one that has been developed against the backdrop of accepted fillable form standards. Don't be too optimistic about being able to integrate it with anything except itself. Even if the form will never be integrated with anything - it will just be used to gather data - be careful about the types of fillable fields that you use.
Secondly, when naming your technical objects, try to build some degree of intelligence into the naming convention and apply this consistently. Calling a form, for example, applicationform.pdf is great if you only ever have one application type to support or if you have an overarching all singing all dancing application form. The same sense of standards should apply to your metadata as well.
Finally, be careful about your choice of an Adobe PDF. Do you really need the data to be entered into a pixel perfect document format? Will an Excel-based form, for example, get you to the same place? Even an InfoPath form may be a better proposition. Excel is pretty ubiquitous these days at least. You don't' have to set Excel, InfoPath or even PDF as the standard but you should understand some of the strengths and weaknesses of each of these document types.
PDF vs Markup Language - Clinton Jones
Microsoft InfoPath or Adobe Forums? - Kristian Kalsing
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week