PDF Association logo.

Facebook
Twitter
YOUTUBE
LINKEDIN
XING
About the contributor
Martin Bailey

More contributions
Participating in the PDF Techniques Accessibility Summit

The PDF Techniques Accessibility Summit’s objective is to establish a broad-based understanding of how PDF files should be tagged for accessibilty. It’s an opportunity to focus on establishing a common set of examples of accessible PDF content, and identify best-practice when tagging difficult cases.

Modernizing PDF Techniques for Accessibility

The PDF Techniques Accessibility Summit will identify best-practices in tagging various cases in PDF documents. Questions to be addressed will likely include: the legal ways to tag a nested list, the correct way to caption multiple images, the appropriate way to organize content within headings.

Refried PDF

My hospital emailed me a medical records release form as a PDF. They told me to print it, fill it, sign it, scan it and return it to the medical records department, in that order. In 2018? To get the form via email (i.e., electronically), yet be asked to print it? Did the last 20 years just… not mean anything! So I thought I’d be clever. I’d fill it first, THEN print it. Or better yet, never print it, but sign it anyhow, and return it along with a note making the case for improving their workflow. The story continues…

Slides and video recordings of PDF Days Europe 2018

You missed the PDF Days Europe 2018? Never mind! Here you can find the slides and video recordings of all 32 stunning sessions!

Using PDF/UA in accessibility checklists

PDF/UA, like PDF itself, is internally complex, but used correctly, actually makes things easier.

PDF 2.0 interop events: risk management and efficiency

Martin BaileyGlobal 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!

PDF 2.0 interop UK, 2017 May 2-3All 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.

PDF 2.0 interop USA, 2017 June 12-13These 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.

 

 


Tags: interop
Categories: PDF 2.0, Standards development