Possibly one of the achievements I am most proud of during more than three decades of developing interactive PDF applications is something that sounds deceptively simple: creating a mini-database capable of managing and storing records entirely within a PDF document. It accomplishes this with a remarkably small footprint without sacrificing the performance or speed expected of a practical desktop application. Perhaps most importantly, the finished application can operate using the free Adobe Reader. No SaaS platform is required. There are no recurring subscription fees, no cloud-based database, and no requirement that a user's records be stored on somebody else's server. In the case of EasyPDF™ Forms, users can also try the software without placing a credit card on hold simply to obtain a free trial.
The Tools Were Already There
What makes this particularly interesting to me is that the fundamental Acrobat technologies necessary to accomplish it are not new. Acrobat JavaScript, document and field methods, the JavaScript object, hidden form fields, and JSON provide the building blocks needed to create a surprisingly capable record-management system within the PDF environment. JSON, which became formally standardized in the mid-2000s, provides an exceptionally compact means of representing structured information. Combined with Acrobat JavaScript and carefully designed PDF form fields, it becomes possible to serialize records, store them within the document, retrieve them, modify them, delete them, search them, and repopulate the visible form fields when needed. Instead of treating a PDF as merely an electronic version of a paper form, I began treating it as an application environment. That distinction changed everything.
A Database Without a Conventional Database
Technically, I don't pretend that a PDF containing structured records is a replacement for SQL Server, Oracle, MySQL, or another full-scale relational database system. Nor is that what I set out to create. The objective was much smaller and considerably more practical. I wanted a self-contained PDF application capable of managing the relatively modest number of records required by applications such as a medication manager, digital Rolodex, password manager, contractor forms, worksheets, and other desktop utilities. For applications of that scale, introducing a database server, cloud service, user account, subscription, or external storage system can create considerably more infrastructure than the application actually requires. My solution was to keep the data with the application. A JavaScript object provides a convenient working structure while the application is running. JSON provides a compact representation of the records. Hidden PDF fields provide persistent internal storage. Acrobat JavaScript ties everything together by controlling how records are created, retrieved, updated, displayed, and deleted. The result is what I refer to as a mini-database in PDF format.
Small Footprint, Surprisingly Capable
One of my principal concerns throughout development was efficiency. It would have been relatively easy to create something that technically worked but became increasingly cumbersome as records accumulated. The more difficult challenge was developing an architecture that remained responsive while keeping the amount of stored information relatively small. That required considerably more than simply knowing how to write a few JavaScript statements. Record structures had to be designed carefully. Reusable helper functions had to be developed. Data needed to be serialized and restored reliably. Form fields needed to interact with the underlying records without unnecessary duplication. Error conditions had to be anticipated. And the entire system had to remain understandable enough to maintain and improve years later. That development process eventually became part of the engineering philosophy behind the EasyPDF™ family of interactive PDF applications.
Why Keep Everything Local?
Today, much of the software industry has moved in the opposite direction. Software increasingly operates through web browsers. Data is routinely stored in the cloud. Monthly and annual subscriptions have replaced many perpetual software licenses. Even some free trials require customers to provide a credit card before they can determine whether the product is suitable for them. There are legitimate reasons for those business and technical models, and cloud-based applications are clearly appropriate for many purposes. But they aren't necessary for everything. For a user who simply wants a specialized desktop application and prefers to keep personal or business records locally, a self-contained PDF application offers a very different proposition. There is no remote database to maintain. No cloud account is necessary for storing the application's records. No continuing subscription is required merely to continue using software that has already been purchased. The PDF itself becomes both the application interface and the container for its structured data.
Hiding in Plain Sight
Perhaps the greatest irony is that many of the underlying technologies have been available for a very long time. The individual pieces weren't the breakthrough. The challenge was figuring out how to combine them into a practical architecture. After performing my own due diligence and searching the Internet for comparable implementations, I have yet to find another publicly documented mini-database in PDF format comparable to the architecture I developed using Acrobat JavaScript methods, the JavaScript object, and JSON to manage and store records within the PDF itself. However, that doesn't prove nobody else has ever attempted or created something similar. It simply means I have yet to find documented evidence of one. And perhaps that is what I find most interesting about the accomplishment. Innovation doesn't always require inventing a new programming language, database engine, or cloud platform. Sometimes it comes from looking differently at mature technologies that everybody else already has. In my case, that meant looking at a PDF form and asking a different question. Not simply: “What information can I collect with this form?” But: “How much of an application can I build inside it?” More than three decades after I began developing interactive PDF forms, answering that question remains one of the accomplishments of which I am most proud.