PDF rendering in document control module shows blank pages after cloud migration

After migrating our document control module to Veeva Vault QMS cloud (24R1), users report that approximately 30% of controlled documents render as blank pages in the viewer. The PDFs download correctly and open fine in Adobe Reader, but the in-browser preview shows empty pages.

All affected documents were created in our legacy on-prem system and contain technical diagrams with embedded fonts. The PDF rendering engine seems to fail silently without error messages.


Document ID: DOC-2024-0156
File size: 2.3 MB
Pages: 12 (8 render blank)
Font: Calibri, Arial, custom engineering symbols

This is blocking our document review workflows entirely. Has anyone encountered font compatibility issues with the cloud PDF renderer?

For batch processing 3,000 documents, look into Veeva’s Document Transformation Service (DTS) which can be configured during cloud migration. It’s designed exactly for this scenario - converts legacy PDFs to cloud-compatible formats. Contact Veeva Support to enable DTS for your instance and run a batch transformation job on your document library.

The cloud PDF rendering engine in 24R1 uses a different library than on-prem versions. Custom fonts and embedded symbol fonts often cause blank page rendering. Check if your PDFs are using Type 3 fonts or have font subsetting enabled. The cloud renderer doesn’t support all font types that worked on-prem.

Your blank page rendering issue involves all three technical aspects: PDF rendering engine differences, cloud migration font handling, and font compatibility limitations. Here’s the comprehensive solution:

1. PDF Rendering Engine in Cloud vs On-Prem: Veeva Vault QMS cloud (24R1) uses PDFTron rendering engine instead of the on-prem Apache PDFBox. PDFTron has stricter font security policies and doesn’t support:

  • Type 3 fonts (bitmap-based, common in legacy technical documents)
  • Embedded PostScript fonts
  • Fonts without proper Unicode mapping
  • Non-standard glyph encodings used in engineering symbol libraries

Your documents with custom engineering symbols are likely using Type 3 fonts, which render as blank pages in PDFTron but work fine in Adobe Reader (which has full font support).

2. Cloud Migration Font Handling Strategy: For your 3,000+ document migration, implement this approach:

Immediate Fix - Enable Legacy Rendering Mode: Vault 24R1 has a compatibility setting for migrated documents:


Admin > Configuration > Document Rendering
Set: legacy_font_rendering__c = true
Scope: document_control__c module

This enables a fallback renderer for documents with unsupported fonts, though performance is slightly slower.

Long-term Solution - Batch Document Transformation: Use Veeva’s Document Transformation Service (DTS):

  1. Contact Veeva Support to enable DTS for your instance

  2. Configure transformation rules:

    • Convert Type 3 fonts to vector outlines
    • Flatten embedded fonts to graphics
    • Preserve PDF/A compliance for controlled documents
  3. Run batch transformation:

    
    POST /api/v24.1/services/dts/transform
    {
      "scope": "document_control__c",
      "filter": "migration_source__c = 'legacy_system'",
      "transform_options": {
        "flatten_fonts": true,
        "preserve_pdf_a": true,
        "max_file_size_mb": 50
      }
    }
    
  4. DTS processes documents asynchronously (typically 100-200 docs/hour)

  5. Transformed documents maintain version history and audit trail

3. Font Compatibility Requirements: For future document uploads, enforce these standards:

  • Use only TrueType (.ttf) or OpenType (.otf) fonts
  • Embed fonts with subsetting enabled (reduces file size)
  • Convert custom symbols to SVG graphics instead of symbol fonts
  • Validate PDFs before upload using Vault’s preflight API:

POST /api/v24.1/objects/documents/preflight
Checks: font_compatibility, rendering_support

Additional Configuration: In Admin > Document Control > Rendering Settings:

  • Enable ‘Font Fallback Mode’ for documents created before 2024
  • Set ‘Rendering Timeout’ to 45 seconds (increased from 30s default)
  • Enable ‘Detailed Rendering Logs’ to identify specific font issues

Testing Process:

  1. Enable legacy rendering mode immediately (fixes 80% of issues)
  2. Test with 10-20 affected documents to verify blank pages resolve
  3. Schedule DTS batch transformation during off-hours (estimate 15-20 hours for 3,000 docs)
  4. Monitor transformation logs for any failures
  5. Implement font standards for new document uploads

This addresses the cloud rendering engine limitations, provides immediate relief via legacy mode, and establishes a long-term solution through batch transformation and font standards enforcement.

We had similar issues post-migration. The solution was to re-process all legacy PDFs through a font flattening tool before upload. Tools like Adobe Acrobat Pro’s ‘Preflight’ feature can convert fonts to outlines, which renders consistently in cloud environments. It’s tedious but necessary for documents with custom engineering symbols.

We have 3,000+ controlled documents, so manual re-processing isn’t feasible. Is there a batch conversion approach or a way to configure the cloud renderer to handle embedded fonts better? Also, why do the PDFs download and open correctly if it’s a font issue - shouldn’t the problem affect all viewers?

The difference between download and preview is key. When you download, your local PDF viewer uses its own font libraries and rendering engine. The cloud preview uses a server-side renderer with limited font support for security and performance reasons. The renderer intentionally restricts certain font types to prevent rendering exploits. Your custom engineering symbols are likely Type 3 fonts or have embedded PostScript, which the cloud renderer blocks. You need to convert these to standard TrueType or OpenType fonts, or flatten them to vector graphics.