Working with PDFs outside of Adobe and Docusign

Portable Document Format (PDF) was introduced by Adobe over 30 years ago as a platform-agnostic way to share paper documents, and has since effectively become the only such format. Despite PDFs being well known and respected to the point of becoming the industry standard, that doesn’t make them the most cost effective  option for digital paperwork. Many of The SilverLogic’s clients are surprised by the expense of integrating with the predominant PDF APIs on the market, like Docusign’s. 

Thankfully, today, there are other approaches available to building in Docusign-like features into custom apps without resorting to market leaders. We’ll walk through some of the more common ones, and a newer technique we are exploring with our projects.

How did PDF become the standard anyway?

In the early days of the internet it was obvious that an operating system-agnostic format was needed so users could share and fill documents on any platform. After nearly cutting the poorly-performing PDF from their lineup, instead Adobe used the expansion of Adobe Acrobat to a wider audience to iterate on the PDF technology, adding features like hypertext linking, interactive UI, password protection, and digital signatures. PDF grew to become the de facto format for digitizing documents.  In 2008, the International Standards Organization (ISO) made PDF the official, global open standard format. Today, PDFs support a number of features, including: 

• Digital signatures 
• Password protection
• Date/time stamping 
• IP logging 
• Embedded multimedia  
• Embedded graphics 
• Watermarking
• Optical Character Recognition
• Data extraction 

PDF’s status as the official format meant a wealth of off-the-shelf PDF apps for end users multiplied, now including resources like APIs and SDKs exist with which developers can integrate tools for the creation, sharing, and filling of PDFs. Healthy competition isn’t necessarily possible with one format standard, though. The market for these tools, particularly ones with easy integration, has been virtually dominated by a handful of companies. Other, newer players in the market are mostly untested, too expensive to be adopted at scale within many apps, or lack the more powerful features, like creating fillable PDFs from scanned documents.   

So what are the typical options to use PDF in your software project? 

Convert a Physical Form to App-fillable PDF in Custom Code  

If you have a given frequently used paper form to be accessed in an app, developers can replicate it in code as a PDF and then map inputs, to its form fields. But, the replication process will be tedious if the form involves a complex layout, and should an app need to generate more than a few templated PDFs, this cost of this approach can quickly add up.   

Convert a Scanned Document to Fillable PDF in Custom Code

Under a traditional programmatic approach, allowing an end user to convert a scan of a paper document into PDF is fairly straightforward. Allowing a user to designate field locations and types (signature, for example), on the other hand, is far trickier than one might expect. Such field mapping logic is holy grail of PDF editing features, and one doesn’t see it often in business apps because it presents an enormous amount of complexity to test and maintain. 

Use Adobe’s or Docusign’s API

Adobe’s and Docusign’s APIs are the most-used for PDF management in custom apps, due to name recognition and their reputation for security. Some companies dealing with strictly regulated contracts rely solely on Docusign, though this is changing. Dropbox and newer AI-enabled providers have been gaining ground in the market since the explosion of apps integrated with ChatGPT and other LLMs, which is helping to demystify PDF management in general for non-technical consumers. 

There is a significant drawback to this choice, however. A SilverLogic client asked us to integrate Docusign into a blockchain project a few years ago. Throughout the integration process, we found key details about their API were either incorrect or missing from their documentation. To cap it off, Docusign’s support escalation team gatekept us from the staff who were actually capable of solving our issues, so we wound up having to spend three times the amount of time we’d estimated for the task.

It’s one thing for the largest potential integration partners for a given technology to fall behind with documentation and support as they grow, but coupled with  ongoing costs of using an integration partner for PDFs being far higher than with other technologies, like email or SMS, we see little reason to recommend this choice in many projects. 

The newer AI-enabled providers do appear promising, but as they have API costs of their own to license the underlying LLM powering their products, their APIs can become about as expensive as Adobe and Docusign. 

Headless Browser PDF Creation & Annotation Method

After experiencing frustration with each of the above options, we started getting creative.

We knew Google had been pioneering developer-facing tools in their Chrome browser for years. In 2022 they unveiled a headless browser resource to allow some of its features to be leveraged within apps, mainly to facilitate data extraction, data scraping, performance testing, and other automations for developers publishing Chrome plugins. We saw an opportunity.

Convert a Paper Form to PDF Using a Headless Browser 

We established a way to convert a paper form to PDF using Google’s headless browser fora logistics company’s dispatch, delivery confirmation, and invoicing automation app. ne requirement was that users be able to input and sign in delivery confirmation form fields, specific to their user role. For example, only a Driver user can log a delivery’s pickup time, and only the end Customer user can sign to confirm receipt of a delivery. But, the client didn’t want to integrate with an off-the-shelf provider due to cost. We leveraged the headless browser to allow users to provide form inputs via an app and then create PDFs from them, allowing the business to reduce workload by thirty percent.

Convert a Scanned Document to Fillable PDF Using a Headless Browser 

We could take the headless browser approach one step further and allow a user to designate the location and type of each field on a scanned document, and then generate a fillable PDF from it. Pair this approach with an LLM like ChatGPT, and you could extend functionalities like automatic parsing and data extraction within your own app rivaling those in market leaders’ standalone products. 

Takeaway: you have options 

PDF pre-dates the Internet, can be unwieldy, yet is unlikely to be disrupted by a new document format anytime soon. Most PDF management APIs are wildly expensive to use at scale, are difficult to integrate, or lack the features needed for many software projects.

Unless your industry or company is wedded to Docusign or Adobe for PDFs or you need every feature they offer, there’s no reason why a developer should rely on pricey market leaders for the more exotic PDF functionalities. You have options. If you wish to build an app involving PDF management and want to discuss what The SilverLogic can do for you, just drop us a line.