PDF SDK Evaluation Checklist

You’re ready to add PDF functionality to your software. But as you race to get your project underway, you have yet to complete technical due diligence⁠—the process of analyzing and evaluating PDF SDKs to ensure you get the best solution for your organization.

According to 2019 market research by global management consulting firm Stax Inc., 70% of the customers of most leading PDF SDKs expressed an interest in switching despite the high costs of doing so. This dissatisfaction implies that evaluating a PDF SDK is a lot harder than it seems. Many customers regret their first choice.

All things considered, PDF SDKs are indeed challenging to tell apart at the surface; vendors all seem to support the same core features, such as viewing and annotating PDFs. And there is little in the way of guidance to help you navigate between competing vendor claims.

In this post, we spotlight areas of difference to help you avoid the intangible costs of choosing the wrong PDF SDK that could force you to switch libraries later.

Here are eight criteria to consider adding to your PDF SDK evaluation checklist:

A mature PDF SDK should provide features such as PDF tiling, linearization, and parallelization that greatly improve performance and limit user network data consumption. (Linearization is crucial for users who expect to tap into massive documents remotely from their mobile devices.)

Without these features, you can encounter behavior such as slow rendering and frustratingly long wait times times for your users, as well as memory consumption and network data transfer issues. Interaction on documents such as scrolling and panning across, and zooming into content may also become slow and frustrating.

Since memory consumption will vary greatly, test the PDF SDK on your users’ preferred documents and processes, browsers and devices. Try interacting heavily with documents: e.g., scroll to the middle, zoom in and out, and pan side to side repeatedly and in various places.

Also test the PDF SDK at an appropriate usage and server load if it is server-based. Some solutions perform excellently when tried on a small number of documents and users but impose unexpected hidden costs when later scaled up.

Certain PDF documents are also intrinsically memory-intensive or corrupted, failing to open or otherwise crashing some viewers.

And for your end users, a single document that fails to open at the 11th hour before they launch or go into production could mean the difference between their success or failure. Users may quickly abandon your app for third-party workarounds if it is seen as unreliable. (See our Construction Computer Software success story to learn more.)

Many people don’t realize the frequency of corrupted PDF documents. And the reason other viewers are able to show corrupted content is because they repair it on the fly. If a PDF is viewable in other readers, users will expect it to be viewable in newer software. Conversely, if the app can’t open the PDF file, users will be inclined to blame the app, not the document.

When you test a PDF SDK, use a large body of documents that capture the variety of what your users will expect to open, and include their most demanding documents, such as documents with very large file sizes (1GB+), complex graphics, or many pages (e.g., 1,000+).

(We also recently tested JavaScript library PDF.js and found documents crashed or failed to open at rates of 1-3% with certain document subsets.)

It is also important to bear in mind that PDF is incredibly complex; the format supports many fonts, embedded formats, languages, and graphics. And PDF files are generated in manifold ways by literally thousands of different tools. As a result, not all SDKs will render PDFs the same way.

Rendering errors may include text with the wrong font, spacing, and kerning, or colors that are displayed without their true brightness or hue. Sometimes these issues are subtle; other times, they are dramatic:

Another consideration is that not all PDF viewers implement the full 1,000-plus-page PDF specification. And when a viewer encounters a PDF graphic or image compression type it does not support, it will not render content correctly. It may not render content at all.

Image quality may also suffer at higher zoom factors when a lower-quality library renders content as raster images rather than as precise, scalable PDF vector.

Don’t take a vendor’s claims that their SDK is mature and battle-tested at face value. Test the rendering engine yourself to evaluate whether your documents will render as expected. Check out our upcoming post on how to evaluate PDF SDK rendering to learn more.

(We also recently went in-depth on rendering issues faced by popular open-source JavaScript library PDF.js.)

You may desire freedom to optimize the UX and streamline the UI to ensure end-user adoption (a critical factor in determining the success or failure of an application).

An open-source UI provides the highest degree of freedom to change the UI and control the UX. With an open-source UI, you get greater early-stage visibility into what can be improved and adjusted. This may be crucial if you have very strict or specific UI requirements. You will also acquire far greater power overall to reskin UI components and change UI behavior, such as adding new annotation types and custom annotations.

If the UI is not open-source already, you can try asking the vendor for access to their UI source code.

Next, end-user needs will likely evolve to include a need for more functionality, file formats, or platforms.

Therefore, check whether the SDK places restrictions on future flexibility.

A feature-rich, cross-platform PDF SDK including client-side and server-side functionality saves you from having to consider adding other libraries later and thus more complexity, or switching libraries and then re-building. Instead, all the functionality you would ever need is already available through a single partner that can enable seamless, long-term growth.

With a format as complex as PDF, you are also likely to need an experienced vendor capable of dealing with new edge cases and undocumented PDF behavior as they emerge.

Therefore, ask the following: Can the vendor quickly pinpoint where problems originate in the core rendering engine? Or will they be reliant on an external third party (including open-source projects) to fix bugs for them?

If the vendor is a reseller or wraps an open-source library such as PDFium, they may not have the expertise to respond as decisively as a commercial vendor who built and therefore, understands their SDK’s rendering engine from the ground up. This may help explain why some PDF SDK vendors rank at a higher Net Promoter Score (NPS) than others.

An experienced vendor should also be able to work with you personally and expose additional APIs should the need arise to meet unique document and user requirements. (See our OEC Graphics success story to learn more.)

Next, there’s always a risk that a hacker could exploit a weakness in a PDF rendering engine⁠—using a boobytrapped PDF, for example, to inject a malicious payload and hijack control over an application, the browser, or the device.

Generally, browser, iOS, Android, and UWP apps are sandboxed to prevent attackers from taking control over the entire device. But an attacker could still steal confidential data from within such as emails, SINs, banking information, and so on⁠—or even documents.

In contrast to mobile apps, server-based and desktop applications are not sandboxed⁠—so an adversary could take control over the device via a PDF SDK weakness.

You will therefore wish to consider the level of security provided by a PDF SDK vendor.

Is their core PDF rendering engine closed-source or based on open-source? OSS is widely deployed, therefore offering a good return on investment to hackers. They will search public repositories and issue trackers for easy-to-exploit vulnerabilities in solutions that have not updated embedded open-source components with known vulnerabilities.

(For more detail, see Apache Software Foundation's Sept. 2017 statement on the Equifax breach.)

Lastly, more eyes on code is also crucial to ensuring an SDK’s continued security and stability. Consider asking the vendor how frequently their code is reviewed by a reputable third party.

A final consideration is whether the SDK fully protects you against third-party legal claims.

Open-source components with certain “copyleft” licenses introduce some risk and uncertainty. For example, a US Federal Court recently ruled an open-source license is an enforceable contract in the case of Artifex (PDF SDK) v. Hancom.

If you are going to use open source directly, make sure you understand the limitations and permissions within the license. (An extensive list of OS/S licences and permissions is available here.)

With a commercial PDF SDK, you may still encounter hidden licensing risks and uncertainties where the vendor embeds open-source software with unclear copyright and patent information. This uncertainty is the case for PDFium, which was originally developed by an independent company and later open-sourced by Google. The agreement between that vendor and Google is not public.

To protect yourself against third-party claims, ask the vendor for a complete list of third-party and open-source software embedded in their PDF SDK.

Also perform due diligence on the vendor. For example, ask where they are located. Do they offer indemnifications in their vendor agreement? (And if so, how much?)

With so many moving parts and such potentially high stakes, a PDF SDK evaluation can be incredibly challenging. But bear in mind the strategies and considerations presented in this post, and you should have an easier time.

We hope this article was helpful! If you have any questions, please contact us. We’d also be happy to chat about providing test files to simplify your evaluation further.

Apryse SDK is a technology platform that brings PDF, CAD, and MS Office capabilities to any software. It’s an easier and faster way to build document functionality.

Stax Inc. survey results found Apryse to have the highest Net Promoter Score and the lowest reported desire to switch among the five leading PDF SDK vendors.

Get started with your free Apryse trial today (no email required) and see the results yourself!