PDF 2.0 interop events: risk management and efficiency

Global Graphics' CTO Martin Bailey explains why the PDF 2.0 interop workshops this May in the UK and June in the USA are so important to PDF tool developers.

A new version of a significant file format that you use in your products is always rather scary for a software development company, especially when it’s as high profile as PDF.

You know that at least some of your customers will decide to make the jump to that new version, perhaps without what you might regard as a sufficient safety net, while others will be blissfully unaware that it’s heading toward them. Many of your more cautious customers will be asking what you plan to do about it, when, and how you are going to ensure that your products minimize their risks.

Of course, you can tell them about your own plans for your own products. That bit is easy.

But when the file format in question is an exchange format for which there are thousands of creation tools, editors, processors and consumers you have to consider how everyone else’s delivery plans and schedules, and the quality of the files created and shared, will impact on your customers.

We’ll all be writing our software to meet the requirements of the PDF 2.0 standard, but there’s always a risk that an engineer somewhere will make one (or more) assumptions that don’t match how engineers from another company expect things to work. An awful lot of work has gone into PDF 2.0 to clarify the text so such assumptions should be much less likely to occur than in previous versions, but it’s still a large and complex specification. The risk is therefore lower, but hasn’t go away completely.

• If you sell a PDF creator, will the other products used in your customers' typical workflows be able to read your files?
• If you sell a PDF consumer, can you deal with the files that other vendors' tools will make?
• If you make an editor or processor you have to worry about both directions!

All of us have contacts in other vendors; that’s one of the benefits of membership of groups such as the PDF Association. It gives you a route to have a quiet word with developers at another vendor when a mutual customer has managed to create a file with their tools that your product can’t consume, or to ask for help when you don’t quite understand exactly what a specification means. So we can work with those contacts to do a bit of early sharing of sample files or queries.

But I, for one, don’t have enough such contacts to be confident that I can do enough testing before everyone goes live with shipping product. I’d much prefer to catch any errors while the code is still in my engineering team, rather than discovering it when a major customer calls and says they’ve got a problem. I want to ensure that my customers will get the best possible experience, which means I don’t want them to hit any difficulties at all, regardless of whether they get tripped by an issue in my code or in somebody else’s product.

I’ve worked on the ISO committee developing PDF 2.0 for years, so I know the benefits that it will bring to my customers. I don’t want the new standard to ring alarm bells in people’s early trials; you don’t get a second chance to make a first impression! If a new standard causes significant pain when people first try to use it, it can take years to win back their confidence enough to fully adopt it. It would be such a waste if that were to happen to PDF 2.0.

All of which is why Global Graphics, in collaboration with the PDF Association, was willing to pick up the challenge of organizing and hosting a pair of PDF 2.0 interop events. Making those events happen is a lot of work … but it’s a lot less than the work of finding alternative ways to achieve the same level of cooperative testing. And it’s a lot less than the amount of work that could be triggered by finding out about incompatibilities once we’ve shipped our products with PDF 2.0 support. Correcting problems in the field is a lot more expensive than doing it before shipping, even if you disregard the impact on your reputation.

These interop events are places for developers from a wide variety of vendors come together and run scaled down workflows to emulate what their customers will do. If I sell a tool for creating PDF files I can share those files with developers from the companies who sell the tools that will consume or edit those files, and we can jointly check that everything works as it should. If it doesn’t work, we can then analyze whether the problem is in the file writing, in the file reading, or a misunderstanding of the new PDF 2.0 specification on one side or the other. Wherever the cause it’s quite likely that one or both of the tools can be adjusted on-site and the test repeated … successfully, this time!

As a member of the PDF Association you obviously care about PDF, and you’ve been kept aware of progress of PDF 2.0 towards its publication. I’m hoping that you’ve already reviewed the text of the standard and have been working towards supporting it in your next product version. If you have then I look forward to seeing you at one or both of the interop events.

Just remember, attending an interop is probably the most efficient way you can find to ensure that your customers are happy with your PDF 2.0 support!

Assembling the test matrix.

Why SHA-1's death makes PDF 2.0 support more important than even before.

Read the press release about the PDF 2.0 interops.