Defining compliance for a PDF reading application

Martin Bailey at 14:29 GMT on 10 August 2010

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

PDF, compliance, standards      5 Comments

5 Comments

Add your comment

  1. Michael Jahn
    10 August 2010 16:02 GMT

    From a printing and prepress perspective – that is, if we are speaking about what a PDF viewer might need to do for a user in that vertical – a compliant reader needs to know how to show if a pdf has bleed/trim. It needs to be able to apply the output intent and embedded profiles. It needs enable you to query “problems” – that is, is the PDF “reliable”. I know this seems like a lot to ask of an “lite” viewing application, but i sure would like to know if a bridge is safe to cross before i step onto it.

    Example ? Many gmail users receive pdf attachments in an email, which is wonderful for probably 99% of the gmail users. If they then select view – The Google viewer does not happen to support and render the embedded color management profiles (I believe it is based on iText).

    This is an example where this tool might not be an appropriate tool for viewing a PDF (Although, I must say, I use this tool every day many times a day)

    Hope this helps !

  2. Martin Bailey
    11 August 2010 09:08 GMT

    Thanks Michael.
    I fully understand your points, but is that level of detail best addressed in the umbrella PDF standard in ISO?
    Would it be better perhaps in a companion technical report to the PDF/X standards, or maybe in a best practices document from a group like the Gent PDF Workgroup (gwg.org)?

  3. Michael Jahn
    11 August 2010 23:46 GMT

    Yes – you are correct – Martin – as a PDF prepress carpenter, everything in my world requires a tape measure and a hammer so I can beat incoming pdf files into shape.

    If i remove my prepress saftey gogles and helmet, and then reply as a normal person opening pdf files created by, lets say, my wife, our bank or accountant for our review, I think the Google iTex viewer or Apple Preview app is fine, but fails if a pdf file requires a password and tends to not even try and display XFA form PDF files. So, we head down the slippery slope of “what is the minimum?” – well, depends I guess. Not sure if that helps much.

  4. Lisa Miller
    12 August 2010 13:24 GMT

    I tend to agree more with Michael on this one. Working with PDF applications more catered to the average home and ‘regular’ business user, I find that it is true that somewhere around 99% of the time the iText style rendering is working just fine. But, I do encounter many customer issues using various regular PDF readers/viewers who are indeed having issues viewing the originally intended file. Therefore, it is pertinent that a better separation is made in terms of standards for determining who gets the ‘seal of compliance’. Furthermore, don’t you see in everyday home and business PDF exchances more and more advanced PDFs? I do, and more often than 1% of the time these are not being read properly by our standard viewers out there. Something’s got to give.

  5. Martin Bailey
    12 August 2010 15:08 GMT

    Thanks Lisa, Michael

    It’s probably unfair to pick on a specific product or PDF vendor, especially when they provide a toolkit that’s integrated by their customers. But I guess I’m going to to some extent anyway …

    Would it be possible for you to provide a list of the problems that you see most commonly with viewers that you use every day. Michael already mentioned failures with password-protected files and XFA; what else?

    Thanks

Post a comment