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.
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.
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.