Hosted this February 17th to 18th, DeveloperWeek is the world’s largest developer and engineering conference. And despite going entirely online it continued as a massive success, bringing 8,500 engineers, software architects, developers, IT and technical leaders from 146 countries to discover and learn about advancements in their fields.

Over 200 speakers presented in various sessions, one being our very own “Do Not Download Your PDF.” Spoiler alert: that’s one of the main takeaways!

During the session, our solution engineer, Andrey Safonov, aimed to help other developers evaluate options for enabling PDF viewing, editing, or annotation in their web applications and navigate the typical developer journey.

In this article, we recap attendees’ discoveries, including the main takeaways from Andrey's presentation.

What Are My Options?

Andrey shared that adding PDF viewing capabilities to a web app is a task often left until toward the end of a project. And when developers begin to look into their options and weigh the pros and cons, it can become overwhelming. So he set out to simplify their journey by laying out and comparing methods for embedding PDF capabilities.

If you missed out on our DeveloperWeek session, you can check out Andrey’s full-length presentation. “Do not Download your PDF - What to Look for in a PDF Library” includes a deeper, side-by-side analysis of methods for embedding PDF capabilities, including two popular open-source options: PDF.js and react-PDF.

Now let’s look at presented options!

Option 1: Let Users Download or Open PDFs in a New Tab

You can think of it as "the easy way out." With this option, users download the file or open PDFs in a new tab on their browser -- often the quickest method for developers, as it requires almost no work. Plus, it's free.

On the other hand, first, by allowing users to download PDFs, you can't enforce any document retention. Once a user downloads, there's almost no controlling how they use the file -- an immediate deal-breaker for those who work with sensitive content. Even added PDF security such as password protection or encryption won't be sufficient.

Next, the content may appear differently on one browser to the next. And browsers won't be able to display any comments or annotations within these documents. So while option #1 may get the job done, especially if you're time-strapped and need to roll out a project ASAP, it will undoubtedly lead to security and collaboration issues.

Option 2: Create a New PDF Viewer from Scratch

Next, Andrey discussed building a PDF viewer from scratch -- a tempting option if you have a capable developer team. After all, why pay for something you can DIY? Well, if you implement all of a PDF specification, you'll be successful at creating your viewer. In the process, you’ll also have created your very own PDF company!

Andrey explained one big sticking point here is that the PDF specification is over 1,000 pages long, not including extensions and supplements. Often, development teams underestimate the effort required to create a viewer. You can have a PDF within a PDF (PDF-ception) as a file attachment, or embed images, videos -- even 3D models. Implementing all of these capabilities can be highly time-consuming. Implementing core PDF features such as transparencies and form filling can take years.

And the PDF specification is constantly evolving with new features, such as those added with PDF 2.0.

Additionally, you'd have to account for all the PDFs that don't follow the PDF specification and are poorly generated. If you don't build a robust "repair engine" to fix these malformed documents on the fly, users will assume something is wrong with your application when their PDFs that open in their other PDF readers fail to display in yours.

Option 3: Leverage an Existing PDF Viewer

The PDF market includes many options, supporting a wide range of capabilities at various price points, from open-source libraries like PDF.js to commercial professional SDKs such as our very own PDFTron SDK. At a glance, it may appear that deploying an existing commercial viewer is costly because it requires you to license or purchase.

But building from scratch drains your developer team of time. And it often ends in companies deciding to leverage a commercial solution anyways, after investing months into developing an in-house viewer or into building custom features like annotations, signatures, and form filling capabilities on top.

Buying a commercial viewer is thus a great way to get a polished product to market quickly while saving your team from reinventing the wheel.

On the other hand, commercial PDF SDKs are not one size fits all. Offered features and capabilities, and the effort required to get them up and running in your app vary greatly. Document collaboration features, for example, typically takes weeks or even months to roll out, even with commercial backing. That's why we’ve worked hard to shorten time to market for our customers with rapid integration options, such as our new WebViewer Collaboration solution. It’s important to thoroughly research and compare your top contenders to find the best fit before committing.

What to Look for in a PDF Viewer

With that in mind, Andrey provided five factors for those evaluating options to consider.

  1. Consistent Rendering Between Browsers -- Not all libraries will render PDFs the same way, and because of that, some solutions struggle with accurate rendering. These rendering errors can include missing text, incorrect fonts, and issues with colors or gradients.
  2. Integration Time -- Some viewers will take considerably more time and effort to integrate into an existing application.
  3. Support for Additional Features -- It’s important to ensure that your viewer offers support for annotations, editing, and any other features you need or would like to have in the future. When in doubt, air on the side of more flexibility in the future.
  4. UI Customization -- See if the UI is easy to use and can match to your desired styling. Those with strict or specific UI requirements will want a look under the hood first. While not provided by every vendor, fully available UI source code offers developers visibility into what they can achieve and complete control over the look & behavior -- advantages that inspired us to open source our WebViewer UI code on GitHub.
  5. Support Team -- As complex as the PDF specification is, you want to ensure you work with an experienced vendor who can answer any questions you have about the integration process, will fix potential issues, and is on top of maintaining the library.

Lessons Learned

Attending DevWeek can be an exciting experience as you connect, hack, and share best practices with developers and innovators from around the globe. And this year was no exception! We were thrilled to participate.

In closing, here are the main takeaways from our DevWeek 2021 presentation, "Do Not Download your PDF".

  • Having users download PDFs from your web application is the cheapest and easiest option in the short term. It's also the least secure and offers next to zero support for adding features, such as annotations or comments.
  • Just because you can build a viewer from scratch doesn't necessarily mean you should; it's often more costly to create a PDF viewer and added features from the ground up than to deploy existing ones.
  • Leveraging an existing viewer or library shortens time to market and enables a better product. Still, it's essential to research contenders to ensure you pick the best option.