Evaluating the Render Fidelity of PDF.js

Every week we work with partners, helping them migrate projects from the open source PDF.js project to our commercial PSPDFKit for Web SDK. This often happens after customer complaints reach a critical level and attempts at fixing the open source code fail.

Meanwhile, our sales team is often asked why customers should choose a commercial solution over a free one. In this post, I’ll talk about the advantages of choosing a commercial solution over PDF.js, with a particular focus on render fidelity.

ℹ️ Note: In this article, I try to be as fair and unbiased as possible. Our foundation in working with our partners is one of trust and mutual respect, and we have no interest in exaggerating for marketing reasons. All bugs are reproducible and public and were verified at the time of writing this article (2 September 2020). If you see any issues with this article, please contact me via Twitter or email.

What’s the Difference between PDF.js and PSPDFKit?

PDF.js started as an experiment at Mozilla to see how far they could push the browser with pure JavaScript rendering. It heavily relies on advanced browser features, which often results in inconsistent document rendering between different browsers or even different operating systems. This makes QA extremely cost intensive, as there’s a need to test Windows, macOS, Linux with Chrome, Firefox, Safari, Edge, and ideally the range of most popular options. Oh, and don’t forget to test mobile browsers, as they also behave differently.

There are also various commercialized variants of PDF.js that use the same render engine. As such, they all have the same problems as the open source version — specifically, they don’t include support for render fidelity issues.

PSPDFKit for Web takes a more nimble approach to document rendering, using the same C++ rendering core that we use across all our platforms. We use WebAssembly to run our existing render core in the browser (via standalone deployment) or on servers (via Docker deployment). This guarantees that we render documents the same everywhere — no matter the browser version or operating system. There will still be differences in how browsers render the user interface, however, we can guarantee that documents look exactly as they should.

Our PDF rendering engine shares code with PDFium, the PDF engine used in Google Chrome and on the Android operating system. This guarantees that it’s widely battle-tested and secure and that it renders correctly. Our fork heavily improves performance, so it still performs well in browsers.

The PDF format is so widely used because it guarantees content looks the same everywhere. Unlike with office documents, render fidelity is a core feature of the PDF format and PDF renderers. So let’s take a look at some of the issues that can come up.

Render Fidelity 1: Washed Out Graphics

The combination of rendering bugs in the PDF.js render engine combined with render bugs in browsers makes it extremely challenging to be accurate.

Problems with rendering can show up as relatively harmless image problems, like this effect where it looks like an inkjet printer ran out of ink:

This is a particularly difficult problem because it manifests in different ways depending on the browser and operating system. You can read up on this issue here. The last comment was six months ago from someone asking “Is there any update on this? Would be really important for us…”

Render Fidelity 2: Blurry QR Code

QR codes are often used to offer customers a fast way to interact with content. In this issue, PDF.js interprets the image mask differently than the PDF standard does, causing the entire code to appear blurry. This bug was reported in April 2014 and is still not fixed.

Render Fidelity 3: Missing Images

Sometimes, render fidelity issues can be downright embarrassing or business damaging. In an issue reported in 2015, some “patterns” aren’t correctly rendered, resulting in Tiffany, Kelly, and Doris not appearing in the picture.

Reproducing Render Fidelity Issues

Since both PSPDFKit for Web and PDF.js render in the browser, it’s easy to test if all your documents work correctly. All of the above issues include the PDF file; simply download it and open it in both viewers.

• Demo of PDF.js
  Use the folder with the arrow pointing upward to load a new PDF from disk.

• PSPDFKit for Web Catalog
  Use the blue Open Document button to load a new PDF from disk.

Remember: PDF.js uses more browser features, which might require you to test this in multiple browsers. PSPDFKit’s WebAssembly engine works independently of the browser version. The browser version will affect load and render performance.

The Value of Quality Assurance and Support

Most of our customers have no interest in running a QA department for their PDF viewer — it should just work. However, all software has bugs; this includes PDF.js, and PSPDFKit for Web as well.

When your customers have issues with documents not rendering as they should, they’ll expect a fix. We prioritize a fast support experience that fixes issues quickly, and we release new tested versions of our SDK every two to four weeks.

PDF.js is maintained by Mozilla and used in the Firefox browser. Due to revenue issues, they recently had to lay off 25 percent of their workforce, which in turn affects future Firefox development. There’s at least one person still working on the project, however, it might take a while until your issue is fixed: There are currently more than 600 open bug reports on PDF.js, the oldest of which dates back to 2011.

What’s important for your business is that you can rely on a document looking correct both in your browser and on all the other desktop and mobile browsers out there. Having to test all browser and OS combinations is extremely time and labor intensive.

If you license PSPDFKit for Web and encounter an issue with render fidelity, we’re here to help. In fact, we regularly fix issues in our render core and even contribute back to Google’s PDFium so that these issues are also fixed in Google Chrome and Android’s native PDF renderer.

Conclusion

While using PDF.js appears to be free, increased support load, development time, and quality assurance testing are all hidden costs. You can avoid these costs by relying on a commercial vendor so that your development team and resources can be spent focusing on what matters most to your particular customers, not on PDF. If you’re interested in seeing the difference, head over to our trial page and download PSPDFKit for Web.