How Portable is PDF?

← Back to Blog

The Goal: Device-Independent Document Exchange

PDF was designed from the ground up to be a device-independent, resolution-independent format for document exchange. Derived from Adobe's PostScript imaging model, it was intended to represent a document exactly as its author intended — regardless of the hardware, software, or operating system used to view or print it. For the vast majority of everyday use cases, it fulfils this promise admirably.

But PDF is not perfectly portable. Over the decades, a combination of Adobe-imposed limitations, third-party extensions, and unintended technical defects have introduced fragmentation. This article examines where the cracks appear.

Note: Michael Peters, Technical Director of Mapsoft, developed the first PDF Export for Adobe PageMaker in collaboration with Adobe Systems. Mapsoft has been working with PDF at a deep technical level for over 30 years.

Adobe-Imposed Limitations

Adobe created PDF and, while the core specification is now an ISO standard (ISO 32000), Adobe has over the years introduced features that create portability barriers:

Rights Management Fees

Adobe's rights management infrastructure — used to apply usage restrictions to PDF documents — has historically required licensees to pay fees. This created a commercial barrier to implementing full compatibility in non-Adobe viewers.

XFA Forms

XFA (XML Forms Architecture) is a proprietary Adobe format embedded within PDF files. XFA forms are not part of the ISO PDF specification. Viewers that do not include Adobe's XFA engine cannot render or process them correctly. Many non-Adobe PDF viewers simply display a blank page or a warning when encountering XFA content.

Proprietary Signing Services

While digital signatures are part of the PDF specification, Adobe has promoted its own cloud-based signing services (Adobe Sign, formerly EchoSign) in ways that tie workflows to its own infrastructure, reducing interoperability with open signing approaches.

Plug-in Developer Restrictions

Adobe's Acrobat SDK licensing terms have imposed restrictions on plug-in developers — including what features can be surfaced, how products can be distributed, and what the relationship with Adobe Reader must look like. These restrictions have influenced how third-party functionality can be built and deployed. Mapsoft has navigated these restrictions throughout its plug-in development work; see our Acrobat SDK platform page for more detail.

WebDAV Commenting Restrictions

Adobe has at various points restricted the ability to use WebDAV-based document workflows for collaborative commenting, limiting this functionality to specific server products rather than open protocols.

Third-Party Unportability

PDF's extensibility is one of its strengths, but it also enables third parties to introduce portability barriers of their own.

Proprietary Security Handlers

PDF supports pluggable security handlers, which means that a document's encryption and access control can be managed by a third-party system rather than the standard password-based encryption defined in the specification. Systems like FileOpen use this mechanism to apply proprietary Digital Rights Management (DRM) to PDFs. Documents protected by FileOpen (or similar handlers) can only be opened by viewers that have the corresponding DRM plug-in installed.

Mapsoft itself has created custom security handlers for clients. In these cases, the resulting PDF files are deliberately designed to be usable only within a specific client environment — portability is intentionally restricted as a business requirement. This is a legitimate use of the specification, but it is worth being aware that any PDF can potentially be protected in this way.

Custom Annotations

The PDF specification allows for custom annotation types beyond the standard set (text notes, highlights, links, and so on). Mapsoft has created custom annotations that are embedded in PDF files for specific client applications. The key to maintaining at least visual portability here is the use of appearance streams: a PDF annotation can carry its own pre-rendered visual representation, meaning that even if a viewer does not understand the custom annotation type, it will still display the appearance stream correctly. The interactivity is lost, but the visual appearance is preserved — this is a well-designed portability mechanism within the specification.

Unintended Unportability

Not all portability problems are deliberate. Some of the most frustrating issues arise from documents that appear to comply with the specification but contain subtle defects.

Corrupt or Incomplete Font Data

PDF files frequently embed font subsets — only the characters actually used in the document are included, rather than the full font. If font embedding is done incorrectly, or if font data becomes corrupt, the document may still render (using font substitution) but with incorrect characters or metrics. Text reflow, copy-and-paste, and text extraction can all produce incorrect results.

Files That Render but Cannot Print

It is possible to create a PDF that displays correctly on screen but fails to print — or prints incorrectly. This typically arises from issues in the PostScript-derived content streams, from transparency handling that the RIP (Raster Image Processor) cannot resolve, or from colour space incompatibilities. Such files expose the gap between screen rendering and print rendering.

Gibberish Text Extraction

PDF text extraction depends on font encoding tables within the file. If a PDF is created without proper ToUnicode mapping (a table that maps font character codes to Unicode code points), then text extraction tools — and assistive technologies like screen readers — will produce garbled output even though the document looks perfectly readable on screen. This is a surprisingly common problem in PDFs generated by older or lower-quality creation tools.

PDF on Mobile: A Significant Portability Gap

PDF forms present a particularly acute portability problem on mobile platforms. The JavaScript object model available in Adobe Reader for iOS and Android is a small subset of the full Acrobat JavaScript API. Interactive behaviours that work reliably in desktop Acrobat — such as showing and hiding fields based on user input, conditional validation, and calculated fields — frequently do not work at all on mobile viewers. This is a significant issue for organisations that deploy interactive PDF forms expecting them to work across all devices.

ISO Standards Fragmentation

The PDF specification itself has fragmented over time. The format progressed through versions 1.0 to 1.7 (which became ISO 32000-1), and then PDF 2.0 (ISO 32000-2). Alongside these core versions, the ISO has published a family of specialised sub-standards:

• PDF/A — for long-term archiving (see our article on PDF/A)
• PDF/X — for print production and prepress exchange
• PDF/E — for engineering documents
• PDF/UA — for accessibility (Universal Accessibility)
• PDF/VT — for variable data and transactional printing

Each sub-standard imposes additional constraints or permissions on top of the base specification. A document conforming to PDF/X may not conform to PDF/A, and vice versa. Claiming a document is "a PDF" does not tell the whole story; the relevant profile matters enormously for specific workflows.

Summary

PDF remains one of the most portable document formats ever devised. For the overwhelming majority of documents — text, images, vector graphics, basic interactive elements — it works extremely well across platforms and viewers. The core of the format is robust.

The portability problems cluster at the edges: in the upper layers of the specification that allow extensibility (custom annotations, security handlers, JavaScript), in proprietary additions (XFA), in the gap between specification compliance and real-world implementation quality (font encoding, mobile rendering), and in the fragmentation introduced by the family of ISO sub-standards.

For most users, these limits are invisible. For publishers, developers, and organisations deploying PDF as part of a critical workflow, understanding them is essential.