Several of the ISO PDF standards committees met in Ottawa, Canada last week; this is a quick catch up on the key points from each.

PDF/A – Archiving

The PDF/A committee reviewed all comments to the final ballot on ISO 19005-2 (PDF/A-2) and ratified the standard for publication. All of the meeting’s agreements will now get rolled into the text, which will then be forwarded to ISO Central Secretariat for final processing. It’s always hard to predict how long that will take, but I’m expecting publication some time in Q1 2011.

We also made some good progress on PDF/A-3, which differs from PDF/A-2 in only one respect: that any file can be embedded within it for a variety of reasons. This can be used to attach source documents (e.g. the Word file you made the PDF/A file from), measurement data used to create a graph, alternative representations etc. The embedded files don’t need to follow the same rules for being meaningfully readable at some distant point in the future as the main PDF/A content itself.

PDF/E – Engineering

The PDF/E committee agreed to start work on PDF/E-2 to enable the archiving of engineering documents. They are running into one of the most common challenges in standards work, however, in that there is widespread demand for the standard, but finding experts willing to invest time in developing it is proving difficult. Volunteers would be welcome!

PDF/UA – Universal Accessibility

The PDF/UA-1 standard is currently in what may be its final ballot before ratification, so wasn’t discussed in Ottawa. If all goes according to plan, that will be published in the second half of 2011, and may even become one leg of the next version of Section 508.

The committee started the work to develop a PDF/UA-2 standard, based on ISO 32000-2 (the next version of the ISO PDF standard itself, see below). That standard already includes a lot of work on accessibility that’s been done in preparation for its use in this way.

PDF itself

All of the comments to the last committee draft (CD) ballot on the next version of PDF (ISO 32000-2) were reviewed and resolved. Several more substantial proposals regarding topics such as what a PDF reader must do and the relationships between the various subset standards were discussed.

The committee decided that the standard is not yet solid enough to go to a ‘Draft International Standard’ (DIS) ballot, which could have been the final stage of the process. Instead it will be updated with the agreements from this meeting and then issued for another CD ballot. The results of that will be discussed in May next year, and may lead to a DIS ballot after then. If so then 32000-2 might be ratified at the end of 2011, and published in early 2012.

That’s it from the great wet North (for some reason the UK and Canada appeared to swap their early Winter weather last week).

Martin

The newly created UK chapter of the PDF/A Competence Centre is announcing their presence with a seminar in London this Friday. There are speakers from Crawford Technologies, Luratech, Callas and the main PDF/A Competence Centre itself … oh yes, and me!

The seminar will look in detail at:

• What is the PDF/A standard and how is it used?

• What are the benefits of PDF/A?

• Which documents can be archived into PDF/A?

• What do PDF/A, PDF / A – 1a, PDF/A – 1b, PDF 2 mean?

It’s being held on Nov 19, 2010 from 1:00 PM – 5:00 PM at:

Hubworking Centre
5 Wormwood Street
London, London EC2M 1RQ

For more details, or to book attendance, see the event web site.

See you there!

Martin

One of the things that’s always been a little vague in the PDF Reference Manual is exactly what an application that reads PDF absolutely has to support in order to be labeled as “PDF compliant”. In the transition to an ISO standard (ISO 32000-1:2008) that didn’t change, but the importance of a formal definition of what a reader must do became more important in some markets.

I’m a member of the ad hoc task force that has been set up in ISO to look at all the statements about reader behavior in the draft of the next version of the PDF standard. The goal is to split them into a number of categories, along the lines of:

• All compliant PDF readers must do these things
• All compliant interactive PDF readers must do these things (but server based converters, RIPs etc don’t need to)
• If a PDF reader supports a section of the PDF standard then it must do this aspect of that section (this is sometimes re-stated as “if the application supports then it must support it properly!”)
• Choosing not to support these features will not make a PDF reader non-compliant.

All of this obviously interacts both with the subset standards such as PDF/A, PDF/E, PDF/X etc, and with a specific buyer’s requirements for the feature set that they need.

I’d be very interested to hear your views on what you think should be the baseline for what every PDF reader must do, and why … or even if you think such things should be left entirely to the market in selecting products that meet specific needs. I’ll use any feedback on this article to help shape my input to the task force.

Thanks