Originally appeared in: Introduction
Now the initial dust cloud is settling, I’ll address this move in two articles. For brevity’s sake, I will provide links for the technical terms used.
First I checked Adobe’s own FAQ for the move to ISO — it is certainly forthright. Perhaps like most others in this business, I next thought: “great idea, just what all the stick-in-the-muds have been waiting for.” Some worthy contributions have appeared in the blogosphere, especially from RedMonk, and the comments on Scobleizer and Duane’s World are also interesting. Overall, the news is well-received.
My participation in AIIM’s PDF/UA (Universal Accessibility) Standards Committee for the past two years has provided some perspective on PDF in real-world standards development terms. Like anyone else, software developers like to set lofty goals for their more considered efforts, while committees tend to punt on the harder stuff. Developer Committees, on the other hand, are notably forthright in their respect for the concerns of unabashed and articulate consumers of the eventual end products. The trick is getting everyone together in the same room – and conceptually, on the same page. Most end-users don’t talk developer-ese, and software standards, of necessity, are developer-oriented documents.
Moving PDF to ISO means that Adobe Systems will submit the format to industry control, allowing third-parties to contribute to the future development of the PDF specification as equals of Adobe itself. One “interested party”, one vote; something of democracy brought to software development.
Why would Adobe do this? First, the PDF Reference, which describes the guts of PDF in programming terms, is already a freely available document, and has been since 1993. The decision to “go for ISO” rests in very large part on Adobe’s success with its PDF products. At the same time, Adobe’s publishing the Reference in theory allowed others to make equally capable software for creating, changing or viewing PDFs. Indeed, the decision to release the PDF Reference was one of the few key moves by which PDF become the de facto standard for electronic documents in the first place.
If it hasn’t always appeared to act consistently with the ideal, Adobe knows that a world awash in PDF is very likely to be a world where Adobe Systems remains a large and important company, not merely a vendor of high-end desktop software to niche markets. PDF remains key to this plan, and releasing PDF to ISO is Adobe’s best possible move in taking that plan to the next level.
At the standards level, regulatory and competitive pressures blend. For many of the same reasons as Adobe, Microsoft has driven its own Standards agenda for OOXML, and it is in a maze of lobbying, legal and technical races with ODF, PDF and other Standards contenders to satisfy various industry bodies and government regulators as to how genuinely open and practical it really is.
Of course, the lowly customer just wants everything to harmonize such that (for example) an authoring document’s structure is entirely preserved in the final-form version. These various standards efforts aren’t structured to complement each other — that would be far too useful. There is competition in standards, as in software, and electronic document technology is a major battleground.
At the end of the day, after the years of hard work that everyone acknowledges are required to move PDF from Adobe’s PDF Reference 1.7 to a full-blown ISO Standard, developers will gain clear and reliable guideposts for their own PDF application development, and their customers will gain new confidence in their technology investments. The result will be more competition; lower prices, better products and more choices for end-product consumers. In the face of OOXML, XPS and ODF, this was a vital move for PDF, and it comes none too soon.
Turning PDF over to the formal open standards process will have one counterintuitive effect, and that is to raise the cost of entry into PDF software development, starting with the fact that ISO documents cost money to read, and the PDF Reference has always been free. ISO’s PDF will set a higher bar for developers than exists today. If consumers demand “ISO PDF”, then 3rd party toolkits will have to be thoroughly revised and updated and PDF developers will have to hit the books. It will become harder to slap together a “make-do” PDF file. The market may compel software developers to support the Standard, and thereby raise their game. These are well-understood and properly aligned incentives — the reason one develops software standards in the first place.
Apart from the massive investment in PDF technologies as demonstrated in their Acrobat and LiveCycle products, Adobe retains an ace: Reader. With the ubiquitous PDF viewer safely in its hands, Adobe retains the capacity to activate capabilities in Reader using keys stored in an ISO-specification PDF file. Others may try to wrest away Adobe’s position as the provider of the best (free) Reader for PDF, but it won’t be an easy task.
One theory has it that going the standards route will allow Adobe to lock in advantageous market positioning for a decade or more. One option would be to eventually turn Reader into Validator, beginning with carefully worded warnings about “pre-ISO” files, eventually by simply refusing to open shoddy PDFs just because they have a .pdf extension. It’s the PDF Standard, not the Reader Standard, you dig?
Let’s set the context for PDF as an ISO standard by reviewing the existing standards work on PDF technology.
PDF/X and PDF/A, the PDF standards work-products that have made it “out of Committee” thus far, are exclusionary by nature. For the most part, they tell you what you may NOT do in your PDF files: PDF/A for archival and PDF/X for high-end print purposes. It is, therefore, relatively easy to write software to check and if necessary, correct, PDFs to comply with PDF/X or PDF/A-1b. Engineers LIKE these sorts of standards, for they grapple with very specific programmatically addressable concerns.
In PDF/UA (Universal Access), we are concerned with what happens when users must employ screen-readers and other sorts of “assistive technologies” to make use of a document. The most obvious example are blind users, who must use screen-reader or Braille transcription software to read.
It is with this focus that PDF/UA confronts directly an issue that also menaces PDF/A-1a and will haunt the PDF Standard as well. This is, in brief, “semantics“, or the logical structure of document content, as opposed to the physical representation of objects on a page. A properly structured document allows viewing software to accurately deliver the author’s intent in the reading method preferred by the user. A poorly structured document, however intelligible to standard-issue eyes when printed, may deliver gibberish when the contents are abstracted for any other purpose.
Quite apart from government’s ability to insist on addressing these concerns, there is a notable business case for preserving content semantics as well. Besides accessibility to disabled users, other benefits for highly accessible documents abound, including improved navigation and search functionality, as well as content repurposing for mobile and other devices and enhanced interoperability generally. Ensuring that document semantics are (a) accurate and (b) persist into the final form is indisputably good long-term policy for documents.
Whether and how the PDF Standard will come to address these questions, or will leave them entirely to PDF/UA and PDF/A-1a, remains to be seen. For the moment, it appears that Adobe and AIIM want all Standards efforts to proceed in their given tracks, which certainly seems like the right course for the present.
According to their FAQ, Adobe’s would like to see the 1.7 Reference become an ISO standard within 12-30 months. Can it be done? If done, what would it mean? There’s a significant gap between the language and terminology of the current PDF Reference and the characteristic language of software standards. As one expert put it to me: “The Reference gives you the words, but doesn’t teach you how to write.” From requirements vs. recommendations to validation tools and implementation notes, there’s a lot of work to be done.
This week and next, I’ll be speaking with a few of the real wizards of PDF to get their thoughts, and to check in on my own, and report on those conversations in a follow-up article.
by Duff Johnson