How CROs & Regulatory Service Providers save time in preparing compliant PDFs
with 3-click automation
How to speed up document-to-PDF conversion by 10x?

How to speed up PDF conversion by 10X in 2021

Reading Time: 5 minutes

Enterprises work with a lot of digital formats: Microsoft Word, Excel, PowerPoint, JPEG, TIFF, PDF, PDF/A, video and audio files. All these digital files need to be converted at some point; for various reasons: standardization, regulatory compliance, digital archiving, customer communication and many more.

Not an easy task, as documents live in different systems, versions, digital file formats etc. And that is where standardization comes in. The transformation to a neutral, generally recognized file format such as PDF plays a big role here.

For many reasons, PDF files (amongst other formats) are created. PDF ensures consistency, helps standardize across different departments and platforms. Thus, it helps increase efficiency in document centric processes. Almost like a one-fits-all file format. 

What is document rendering? What does document rendering mean?

The conversion of different file formats to PDF is often also referred to as ‘document rendering’. Converting documents is generally handled by very specific applications & systems, the so-called ‘rendition engines’. This ensures the transformation of one digital file format into another, f.e. PDF.

Document rendering can be done in different ways. The most common approaches are:

  1. By making use of the ‘authoring’ application that was used to author the original document (Microsoft Word, OpenOffice, Microsoft Excel, etc.)
  2. Standalone document rendering, without using the authoring application(s).

Both approaches are very different, and vary greatly in terms of speed, quality, configurability. This article further explains the inherent differences of both. 

Rendering through the use of the authoring applications (f.e. Office, Adobe, …)

This approach is being used today by most organizations and is the most common way of creating a PDF. As an example, this is what happens during a Word to PDF conversion with this approach.

  1. The first step is to retrieve the Word file from where it resides. Within large organizations, content can be stored in multiple places: Document Management Systems (DMS) such as: OpenText Documentum, Veeva, Microsoft SharePoint, Box, Alfresco, Generis CARA, Hyland etc. 
  2. The rendering engine connects to the existing Document Management System(s) and pulls the original Word file from there. Or the file is being sent over.
  3. The rendering engine then calls the authoring application (for a Word file, the authoring application is Microsoft Word. For PowerPoint, is Microsoft PowerPoint etc.) to open the original source file.
  4. Subsequently, it performs a Print to Postscript action using an Adobe Distiller or other printer driver. 
  5. The rendering server then starts Adobe Distiller or equivalent and the Postscript file loaded, which is then converted to PDF. 
  6. All authoring and Adobe applications are finally closed, and the PDF is sent back to the Document Management System(s). 
  7. The PDF file is stored as a rendition to the original Word document or as a new object. 
  8. The process then repeats for the next Word file.

So far, so good. The conversion of a Word file to PDF through the authoring application. But, what happens in reality?

”Rendering by using the authoring application
introduces risks.”

Based on the conversations with industry experts, and our customers, this PDF rendering approach has drawbacks:

  1. The authoring applications (Office and Adobe tools and everything else) need licenses. And these come at a price. The number of documents to be converted and the organization size impacts licensing cost. All these authoring applications must also be upgraded, patched and validated. All in all, this brings big (and often overlooked) costs for most organizations. Especially when you consider how many different formats should be converted to PDF. (PowerPoint, Excel, Word etc.)
  2. Rendering through the use of the authoring applications introduces risks. A simple version difference (Word version installed on the desktop vs. Word version installed on the rendition server) can cause all PDF conversions to fail, potentially bringing the entire process to a stop. In some cases, Word documents containing specific settings, have caused the rendition server to inherit these settings, causing incorrect renditions.
  3. Rendering through the use of the authoring applications is slow and burdensome: For every PDF conversion request, the authoring application opens the source file(s). This process, multiplied by thousands of documents for each submission package, can add up to weeks or longer.

Document conversion is being used by many departments (marketing, HR, labelling, regulatory etc.) throughout a large organization. A slow or failed conversion process quickly becomes very costly

Time to market is critical, so coming up with solutions to the above challenges is key.  PDF conversion should be easy, automated and as cost-efficient as possible.

‘’Rendering through the authoring applications is risky, expensive and slow. Is there a more efficient way?’’

What can significantly improve the PDF rendering speed?

Standalone document rendering: PDF conversion without  needing Microsoft Office

DocShifter doesn’t need any authoring applications to perform PDF or any other conversions. Thanks to this architecture, our customers see a 66% cost reduction in IT infrastructure. (licensing, number of servers etc.) Risks associated with authoring applications (slow conversions, extra costs, manual interventions etc.) are simply eliminated. 

Moreover, DocShifter doesn’t need any authoring applications to run. This significantly improves the conversion speed: 10x faster than comparable solutions.

Docker container technology further empowers the document conversion capabilities of DocShifter. When organizations have the pressure to convert thousands or millions of documents in a very short amount of time, peak loads are easily dealt with.

DocShifter’s standard configurations for FDA, PMDA, EMA and other health authorities allow consistent and automated submission-ready PDF creation. In one go. 

Thanks to native integrations and open API’s, DocShifter connects with any DMS or RIM system. This open connectivity greatly reduces the risk and increases the efficiency, as content is stored in multiple repositories. Document conversion is centralized in 1 platform, for all departments. 

About DocShifter: PDF conversion server without Microsoft Office

Speed, quality, scalability, and configurability are reasons why organizations all around the world choose DocShifter for their document and content conversion. High volume, high-quality document conversion, on-premises, or in the cloud. Super easy to set up. Automate. Centralize. Eliminate manual intervention. Reduce risk. Reduce IT infrastructure costs.

Did you enjoy this article?
Find more in our free LinkedIn newsletter.