PDF/UA, like PDF itself, is internally complex, but used correctly, actually makes things easier.PDF Association expands its board of directors
Catherine Andersz of PDFTron Systems, Alaine Behler of iText Software and Peter Wyatt, ISO Project Leader for ISO 32000 enrich the newly elected board of the PDF Association.PDF Days Europe 2018 concludes with record number of attendees
Richard Cohn, Principal Scientist at Adobe and the co-author of PDF 1.0, gave the opening keynote at the PDF Days Europe 2018.Interview with René Treuber, Product Manager of axaio software, about PDF Days Europe 2018
René Treuber, Product Manager of axaio software, will be hosting a presentation titled “Introducing ISO standards for PDF “processing steps” and “print product metadata”” at the PDF Days Europe 2018. In this Interview he gives some background information about it.Interview with Roman Toda, CTO of Normex, about PDF Days Europe 2018
Roman Toda, CTO of Normex, will be hosting a presentation titled “Encryption with PDF 2.0” at the PDF Days Europe 2018. In this interview he gives some background information about it.
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.
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.