For some reason David Stevenson’s last blog post brought a comparison between email attachments and blood types to mind. A person with type O blood is often called a universal donor, because (almost) everyone can be safely given their blood in a transfusion. In the same way, a person with type AB blood is called a universal recipient, because they can safely be given blood from (almost) anyone else.

David effectively described a PDF file as the universal donor for email attachments, like type O blood. You can be pretty sure that the recipient will be able to read it and see the same page layout, images, fonts, text etc as you did before you sent it. So if you want the recipient to be able to access documents as easily as possible, and to read through them in the way that you planned, a PDF is the best way to go.

But just like all best practice, you just know that not everyone will follow it. Your own organization’s internal guidelines often won’t help when you’re receiving files from outside your firewall.

You therefore have to consider not only how you will send email attachments, but also how you might want to handle those that you’re sent by other people. In a sense you need to be a universal recipient as well as a universal donor. This is where the blood type analogy breaks down, because it’s not possible to be both for blood transfusions, but you can do both for email. All you need to do is make sure that you have the tools to read all of the formats that people are likely to send documents to you in … and then ideally to convert them to PDF to let you forward them to your colleagues and follow best practice for delivery!

The reasons for attaching to an email a PDF (or XPS) instead of the original Word, PowerPoint or other application file are well understood. PDFs are cross platform, usually a good deal smaller, and pretty much guaranteed to display on the recipient’s device (whatever that may be) as the sender sees it on his or hers.

They are also very useful for aggregating a number of items together. I get really irritated when I get sent a bunch of attachments. Recently I was sent some property particulars by an estate agent. If they had been a few PDFs perhaps that wouldn’t have been so bad, but instead they were Word files and digital images. I was immediately put off – it gave me the impression that the sender wasn’t taking the trouble. How much easier it would have been to receive what I immediately created for myself in just a couple of minutes: a PDF with the particulars and the photos, in the right order, and with some bookmarks corresponding to each property.

In this case I was motivated because I was interested in the information, but how often in business does “attachment overload” create a poor impression? When agencies send out multiple CVs, in different formats, for example? Or banks, sending their private clients investment information? The aim surely is to give the recipient something that is easy to deal with. So take the time to assemble the information in an easily consumed form; PDF is an ideal format for this. Your prospect will appreciate it; the last thing you want is for him to say to himself “I can’t be bothered with this” and delete the message.

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