When Adobe Systems began expanding PDF beyond the original mission of a portable file with reliable printed output, they added navigational, interactive and other features intended to improve the end-user experience. Hence, Acrobat became RAD = Rapid Application Development (Wikipedia definition).
Beginning with links and bookmarks, then adding form field elements, buttons, javascript, movies, full-screen mode, transitions, templates, layers, XML and more, each new version of Acrobat has seen a corresponding update to the PDF Reference, the document that describes (technically) the PDF format. When introducing JavaScript for PDF in the mid 1990s, Adobe published the first of the (excellent) Acrobat JavaScript Scripting Reference documents to assist Acrobat developers (and even developer wannabes) in doing their thing.
And what is that “thing”? The original idea was to give form-developers a way to build interactive PDF forms using javascript; forms that could calculate, validate and display changes based on user input.
Beyond business forms, PDF developers began making other “information applications” with interactive PDF files, including “kiosk” applications such as interactive brochures, slide-shows, training materials, CD and DVD-ROM interfaces and stand-alone document collections.
While PDF doesn’t offer all the whizzy effects available to Flash developers, it is powerful, flexible and stable enough to offer a more-than-capable alternative to Flash in many situations. In particular, PDF serves uniquely well in terms of delivering seamless continuity between navigation content and document content. There are other advantages as well – but that’s for another post.
Is Acrobat 8 a step forward for “Acrobat as RAD tool”? The fact that Acrobat Professional 8 can enable PDFs so that the free Reader can save a form’s contents is a dramatic and very positive move, without a doubt. Whether the user can save a partially-completed form – seemingly such a simple idea – can (and often does) decide the question of whether PDF is an appropriate format for a given forms application. With Acrobat 8, that question is now put to rest.
That said, while Adobe has put their steroids into commenting and other features, Acrobat’s RAD tools remain largely unimproved since Acrobat 5. It’s a real shame, considering the exposure such applications offer PDF in a serious value-added context, not merely as electronic paper. With XPS on the horizon and third-party PDF creation tools proliferating like veritable weeds, the “RAD platform” qualities and potential of Acrobat and PDF are becoming, one hopes, ever more evident in San Jose.
PDF kiosk application developers and users still contend with showers of largely valueless warning dialogs. Up to and including Acrobat 8, the application assumes that every PDF that includes fillable form-field elements must therefore logically be a form… and thus the user must be warned that they can’t save it. What a narrow way to understand the power and utility of form-fields! It’s also perfectly plausible that this PDF is NOT a form, but is instead a self-contained application – a delivery, navigational and interaction system for a body of content, leveraging the toolkit Adobe still seems to think is “only” for forms.
Serving up a warning that the user “can’t save” the file is fine as a default, but clumsy details like this have obstructed the development of interactive PDFs for years. Developers should be able to simply turn off this warning, or otherwise place the document in “kiosk mode” at runtime.
I am, however, happy to report the news that in Acrobat 8, there finally IS a way around the “Reader can’t save” warning that so frustrates PDF developers. Use Acrobat Professional 8 to enable Save rights in Adobe Reader, and… guess what! No more warning! That’s one way to do it… and it works!
Originally posted on Duff Johnson’s PDF Perspective blog for acrobatusers.com.
by Duff Johnson