Although PDF is an ISO standard, it also includes various other standards like PDF/A and PDF/X, intended to enhance its portability. Nonetheless, several factors can render it unportable. Adobe deliberately imposes some of these limitations to maintain control over the format and the functionality of their products, such as Adobe Acrobat, that interact with PDFs. Third parties impose additional limitations.
The question is how close PDF is to being truly portable across all devices and whether this portability is improving or worsening over time. Let’s examine the initial definition of PDF.
A definition of PDF
The early PDF specification versions have largely stayed the same in this section for PDF 1.7, PDF 2.0, and the ISO standard, outlining the PDF ‘ideal’.
The goal of PDF is to enable users to exchange and view electronic documents easily and reliably, independent of the environment in which they were created or the environment in which they are viewed or printed. At the core of PDF is an advanced imaging model derived from the PostScript® page description language. This PDF Imaging Model enables the description of text and graphics in a device-independent and resolution-independent manner. To improve performance for interactive viewing, PDF defines a more structured format than that used by most PostScript language programs. Unlike Postscript, which is a programming language, PDF is based on a structured binary file format that is optimised for high performance in interactive viewing. PDF also includes objects, such as annotations and hypertext links, that are not part of the page content itself but are useful for interactive viewing and document interchange.
So the big question is how close is PDF today in reaching this “goal” envisioned by its designers?
Adobe Imposed Unportability
Adobe has made PDF an ISO standard. Yet, some argue Adobe still treats it like a proprietary format. This strategy may aim to keep users within Adobe’s ecosystem, favoring applications like Adobe Acrobat. Adobe employs several methods to achieve this.
- Rights management and charging large fees to those companies that want to create there own DRM systems that allow files to be open in the free Adobe Reader. To most organisations these fees are often unaffordable.
- Keeping XFA forms proprietary.
- Introducing their own proprietary signing service.
- Reader extensions to enable commenting on PDF files. Although with later versions of the Reader this has steadily become more relaxed.
Licensing and moving the goal posts.
Does anyone remember Business Tools or Acrobat Exchange (a cut down version of Adobe Acrobat)?
Anybody who wants to produce a plug-in for the Adobe Reader must first receive Adobe’s approval. Essentially, even if a third party seeks broad acceptance for their functionality, Adobe retains the right to reject it. Recently, Adobe restricted access to the Reader (RMSDK) that developers could use to modify the Reader on mobile devices. Starting from Acrobat XI, Adobe removed the ability to save comments on WebDav, forcing companies to use Acrobat.com services instead.
There many other examples.
Opportunities for third parties to introduce Unportability
Although many third party developers will want to try and keep their PDF files as portable as possible, especially if they are creating tools to create PDF files, there will be others attempting to turn the PDF files into a proprietary format again.
Security handlers
Security handlers such as that produced by FileOpen Systems change the encryption in the PDF file according to encryption Algorithms known only to FileOpen. How many other security handlers are utilised is an unknown because this is information that is not published. For example, Mapsoft has created customised security handlers for several of our clients. These files are rendered useless outside the client environments and this is a deliberate action to ensure that these PDF file are not portable.
Custom Data
Data saved in PDF files from third party plugins and applications. Plugins often save information that is specific to them in the PDF file. Users or systems can embed custom annotations, preference data, and proprietary data formats into the file, apart from the security handlers mentioned above.
Custom Annotations
On numerous occasions my company has created custom annotations that become embedded in the PDF file. It is largely because the existing annotations don’t provide the functionality required by the customer. This functionality is normally provided by a custom plug-in for Adobe Acrobat. Custom annotations normally leave their appearances in the PDF file, allowing the PDF to be viewed even without the Annotation handler. This approach maintains the PDF files’ portability, enabling viewing while removing the ability to modify them.
Unintended Unportability
On many occasions we have received files from customers that appear to be sound only to find some glaring errors in the structure of the PDF file that is rendering it useless to any further processing or even viewing.
The issue of corrupt fonts or incomplete font information is often a cause of problems. Rendering the file may be possible. We have seen instances where a PDF file will render on screen, but it can’t be printed.
A PDF file may be ok to render and then when further processing takes place such as the editing of images or text there is a failure inside Acrobat. On some files the extraction of text outputs gibberish because there wasn’t enough information in the PDF file to translate the font encoding. Some font information it purely graphical and there is no way of reliably creating text from this information.
Mobile Use
One of the most problematic areas of portability is on mobile devices. You might think producing a PDF to work seamlessly on iOS or Android is straightforward. However, even Adobe Acrobat Reader for Mobile on these platforms doesn’t guarantee it.
An example I have come across recently is in the use of PDF forms. Now I am not talking about XFA forms which I believe is still a proprietary format but the standard forms that have been available for PDF since the 1.2 version of the standard. Before the 1.7 version of PDF became an ISO standard (ISO 32000), you could align the version of PDF with a specific version of Acrobat by adding the major and minor versions of PDF together. Therefore, we can deduce that the introduction of PDF 1.2 was for Acrobat 3, released in 1996.
In any PDF form it should be possible to provide some level of interactivity for users and it is in this area where forms viewed on mobiles are severely lacking in their support. In recent work for a client we needed to introduce some functionality into the form for the following:
- Showing hiding fields based on responses to previous questions on the form.
- Showing form outlines in red when an entry is required and removing this when the field has been filled.
I would argue that neither of the above expectations are unreasonable. However, the Adobe Reader for iOS or Android does not support them due to the simple fact that it supports a tiny JavaScript object model. I have yet to find a third-party viewer that actually documents what they support in this area.
ISO Standards
Summary and Conclusion
PDF is one of the most portable file formats, yet it’s not without flaws. Its flat file nature ensures broad portability, but the upper layer of Annotations often introduces issues. PDFs are ubiquitous across industries and websites, with nearly everyone using a computer familiar with them. We hope for significant improvements in the coming years to enhance its portability. Now that PDF is an ISO standard it is the responsibility of the developer community to ensure that this happens. However, there will always be the commercial pressures to personalise PDF, to create yet another sub-standard, but perhaps that is the beauty of the format.
