Document Cloud SDK: Unlocking PDF

You might have missed it…

in March Adobe quietly released it’s Document Cloud View and Services SDK to developers. PDF has been on a slow but steady march towards becoming more accessible to create, convert, and consume since it was made an ISO standard in 2008.   The Document Cloud SDKs are a giant step forward along this path.

View: Power and Transparency for In-Browser PDFs  

Browser vendors like Apple and Google and some desktop applications have leveraged the ISO standard to provide their own embedded PDF viewers. Experiences can differ greatly as these vendors can decide which parts of the massive PDF specification they choose to implement.  Some support annotations, form fields, and signing while others do not.  This makes it extremely difficult to ensure everyone consuming your PDF content has a consistent experience.   Measuring and analyzing the user’s experience has also been a challenge as web analytics has not been able to penetrate the black box that is PDF.

The Document Cloud’s View SDK solves these challenges simply. It allows you to embed a PDF viewer into your applications with only a few lines of code. There is nothing to set up beyond registering for a credential key. The code invokes Adobe’s HTML-based viewer, faithfully and consistently renders the PDF, and provides the developer with control over the viewing experience. Controls include how the viewer is embedded, what application ‘chrome’ features (annotation tools, zoom, download, etc.) are visible, auto-save, and workflow customization (controlling actions related to saving files, file status, and user profiles) through callbacks. The easiest way to wrap your head around the View SDK is to try the online demo, then read the View SDK documentation to understand the possibilities.  Probably the most compelling capability of the View SDK is the ability to gather web analytics. A pre-built integration with Adobe Analytics lets you gather and visualize PDF viewing and reading habits.   If you are not an Analytics customer, you can still capture the rich set of event data with JavaScript.

Adobe has also just added a new PDF Viewer Core Component, which makes it easier to embed the Document Cloud Viewer to expose PDF assets in web pages.   The combination addresses a previous gap in AEM Asset Insights which only provided usage tracking for images.

‍

Services: Create, Combine, and Export PDFs in the Cloud

Even more exciting (I think), is the Services SDK. This SDK provides an Adobe public cloud service for converting MS Office files and HTML to PDF, exporting PDFs to Office and images, combining PDFs, and recognizing text in scanned PDFs using OCR.  Traditionally these capabilities have been available only as part of enterprise server software (at corresponding prices) or as libraries where the developer was left to work out the scalability and availability challenges on their own. Providing these as transactional cloud services really makes this functionality more accessible to the developer. With a few lines of code your application can leverage these services. To that end, Adobe provides .NET, Node.js and Java examples to get you started.  

What’s Next?

Adobe hasn’t said much at this point about future plans for the Doc Cloud SDK - from either a technology, or a go-to-market point of view.  

The free developer trial provides processing for 5,000 pages (FAQ), but for commercial use you need to speak to an Adobe account rep. For adoption purposes, I can see Adobe providing developers with a way to purchase transactions by credit card. However, if individual developers were the target, Adobe would probably already have a credit card option in place. Adobe is more likely to monetize this service through partnerships with other software vendors or direct sales to enterprises. To tackle these markets, Adobe needs to prove the reliability and scale of the services over time.  

From a technology perspective, the most obvious next step is to provide a REST API and make it a true Adobe I/O API. Native SDKs such as .NET/Node.js/Java are great for experimentation and self-managed applications, but leveraging these services from other cloud applications requires RESTful APIs. Another member of the Document Cloud - Adobe Sign - provides a REST interface for integrations which workflow software vendors like Nintex use to offer Nintex Sign. A REST API would provide endless possibilities when used in conjunction with Nintex’s powerful yet simple document generation and workflow. The same is true, for many other cloud vendors. It’s also easy to imagine an expansion of the service functionality - more file formats and advanced features like redaction, accessibility, optimization, or producing and validating PDF/* (PDF/A, PDF/X, etc.) files.

No matter where Adobe takes the Doc Cloud SDK next, it will be exciting to watch and build on a fantastic first step to unlocking the power of PDF.

‍