Performing due diligence on commercial software can be demanding in its own right. You’re working under pressure to get the project to market as soon as possible -- but the consequences of a wrong decision could weigh on your organization for years.
If you’re considering a PDF.js-based project, this article provides a detailed guide sourced from real-world PDF.js implementations.
As a vendor of a commercial PDF SDK, we hear from customers who come to us after trying PDF.js and finding it cannot meet their needs.
Based on our research, the number one reason PDF.js deployments fail is due to the difficulty of adding more functionality. Developers possibly underestimate the complexity of PDF and the amount of time and effort required by a PDF.js-based customization.
(To learn more about other aspects like functionality and performance, read our comprehensive guide to PDF.js .)
Survey: Why Organizations Switch from PDF.js
To test this hypothesis, we surveyed 57 unique organizations who came to us after trying PDF.js and finding it could not meet their needs. Many of these organizations consisted of OEMs and enterprises from industries such as construction and engineering, publishing, finance, legal, education, and life sciences.
These organizations ultimately deemed PDF.js unacceptable for one of the following reasons:
Notably, of the 42 organizations who wanted more functionality, 71.4% tried to implement that functionality themselves first with PDF.js -- and found it too difficult or time-intensive.
The Costs and Risks of Customization
If you are thinking about a PDF.js customization, you may wish to consider the following:
- The time it takes to learn and build new functionality
- The ongoing costs of supporting and maintaining custom features
- Bugs and other open issues that may require your attention
- Your requirements for accuracy, reliability, and speed
- The risk of delays or abandoning a project
Why Adding Features is Time-intensive
The challenge of a PDF.js-based customization is that PDF.js was intended as a PDF reader and Firefox’s integrated PDF viewer, as Dropbox wrote after abandoning a PDF.js-based project:
~Senior Developer, Dropbox
Due to it being an open-source project not intended for use in other products, PDF.js lacks the conveniences of a commercial PDF SDK that would streamline development.
Out-of-box functionality is limited to viewing capabilities. You will be required to build additional functionality in-house or by using another open-source project, of varying quality and completeness.
PDF.js does not have an API for adding functionality to the UI. Thus adding certain features like annotations -- attempted by 42% of 57 surveyed organizations -- will prove challenging and time-intensive. You will need to familiarize yourself with the PDF.js code base, itself complex and assuming familiarity with the PDF specification.
The PDF specification is very complex:
~Senior Developer, Dropbox
Achieving familiarity with the PDF specification will entail acquiring specialized knowledge and expertise, which will take time. When adding annotations to PDF.js, for example, you will have to learn how to handle basic rendering instructions, including how to convert PDF annotation coordinates to
~Senior Developer. Dropbox
Documentation is often absent, stale (many broken links) or incomplete because PDF.js is maintained by volunteers working without consistent oversight or quality control.
Support may be unreliable. You will have to rely on voluntary forum responses, and depending on the complexity of your request , answers may be slow or inadequate. If your request falls outside the scope of the project, you are largely on your own.
Certain features may need to be rebuilt -- like PDF.js text-select and text-search , which may not deliver the desired UX out-of-the-box.
~Senior UX Consultant, Fortune 50 Software Company
All told, your team may spend months to learn, build, calibrate, and optimize new and existing features.
Why Maintaining and Supporting Features is Time-intensive
Additionally, you will have to invest time into feature support and maintenance. Since PDF.js is an open-source project, it cannot guarantee code stability and backward compatibility.
It is important to bear in mind that PDF.js, unlike a commercial SDK, is under an Apache License 2.0 -- without warranties or liabilities for defects or regressions should either be introduced by a community contributor.
With over 6,000 forks of PDF.js, commits happen on average several times a week, and these changes are not necessarily performed with your project in mind:
You may find that community fixes lead to undesired rendering behavior or removal of certain features:
~Andrey Safonov - PDFTron Solutions Engineer
Many open issues stem from difficult-to-fix aspects of PDF.js such as issues related to the core rendering as well as text parsing engine, responsible for defining the text overlay used for text select, text extraction, and text search. (PDF.js text-select alone has 90+ open issues, more than any other single issue category.)
You may be required to own these issues as well to satisfy your users’ performance, rendering accuracy, and feature requirements.
After investing months or years into a highly customized viewer, you may ultimately find that PDF.js is unable to meet your document performance, reliability, and rendering accuracy requirements.
Next to difficulty building functionality, almost half (45.6%) of 57 surveyed organizations cited either performance, reliability, or rendering accuracy as their primary reason for switching from PDF.js.
Here are just a few of these customers’ testimonials:
~Developer, Fortune 50 Company
~Developer, eLearning Software
~Solution Architect, Life Sciences Software
~Technical Director, Document Management Software
~CTO, Training & Compliance Software
~Co-founder, eDiscovery Software
~VP, Software Consulting Firm
~Developer, eLearning Software
~Developer, 3D Mapping Software
When to Use PDF.js
PDF.js affords a few advantages as a simple, short-term solution:
The project layers (core PDF parsing and rendering, the display API, and the example viewer) are nicely separated. Installation is a breeze if one wants to use the example viewer layer or implement a custom viewer with limited functionality. Most of PDF.js’s dependencies rely on universal web standards. And basic UI elements, such as buttons, can be restyled quickly via the project CSS and HTML files.
PDF.js may, therefore, prove cost-effective in the following situations:
- Users are willing to tolerate some rendering, performance, and reliability issues
- Where your project scope is limited to basic viewing
- The project is a short-term solution
- The PDFs are small and simple
Case Study: Slack - Where PDF.js Worked
Three years ago, Slack embedded a PDF.js viewer using only the resources of a single recent hire.
The organization was able to trim the viewer UI to an easy-to-maintain minimum of features and achieved basic viewing primarily for small PDFs (e.g., invoices, contracts, and sales reports).
They then blogged their success:
~Senior Developer, Slack
However, despite first hinting at further iterations, after the passage of three years, Slack hasn’t added more features to its PDF.js viewer such as annotations, form filling, or signatures -- features that would let users do more with their PDFs in Slack.
Instead, there are now third-party tools in the Slack App Directory that offer a few PDF capabilities, such as form fill. And these tools require a separate purchase or subscription.
Where PDF.js Fails
Some of our customers testify that adding more features to PDF.js such as annotations, form filling, and signatures may prove very challenging and time-intensive.
~Senior Developer, DMS Software
~Developer, Legal Software
Therefore, a PDF.js-based project may not prove cost-effective if any of the following are true:
- The web viewer will be heavily relied upon in an organizational setting or commercial product
- Feature requirements are more advanced
- Users will expect functionality to grow over time
- The UX needs to be a competitive differentiator
- Users expect rendering accuracy
- Documents include the large and complex
The Bottom Line
~Mark Holst-Knudsen, President ThomasNet @ MIT’s 2014 CIO Symposium
What the question of build vs. buy comes down to in a majority of cases is whether the total costs of an in-house build (time spent learning, building, maintaining, and supporting custom features) has a lesser impact on your bottom line than the price of a commercial SDK license.
With these considerations in mind, PDF.js may prove good enough where you need a fast, short-term solution for web viewing small and simple PDFs. In contrast, PDF.js may not be as dependable, flexible, or scalable as required if your web viewer will be heavily relied upon in a commercial product or organizational setting; where your feature requirements are more advanced; and where performance, reliability, and rendering accuracy are important.
However, if you require faster performance, reliability, and near-flawless rendering, as well as easy access to hundreds of unique features cross-platform, and accelerated time to market -- then you may wish to consider a commercial solution such as PDFTron SDK.
We’d love to hear any feedback you may have about this article or our PDF SDK. Don’t hesitate to contact us directly.