Here’s a conversation I have quite often with CIOs and IT managers, not to mention ECM industry people.

It usually starts like this:

ME: Does your ECM system support PDF documents?

CIO: Of course our ECM system supports PDF! I look at PDFs on it everyday! Just about everything in the system is a PDF!

That’s always good to know. OK, so then I ask…

ME: So, you know how you can add notes to PDF pages in Acrobat, Power PDF, Nitro, etc – all the various “paid” PDF viewers, right?

CIO: Of course. I do that a few times a day.

ME: You do that to PDF files in your ECM system?

At this point there are several possible answers I get with some regularity. Two such representative answers might be:

CIO #1: Yes! I mean… no, not exactly. I copy the file out to my desktop, add the note and email the file (or whatever else I need to do with it). I don’t check it back in because the ECM system makes a new version, and it doesn’t seem to import the notes.

CIO #2: No. We can make notes about pages in the ECM system, but it’s not on the PDF. I do know that if I need to send the file to someone who doesn’t have access to the ECM, the notes aren’t available to them.

Now it’s time for me to point out the issue.

ME: So, PDF has this feature (portable annotations) that makes a lot of sense. Users like it and stand-alone PDF viewers support it. ECM systems do not connect their own note-taking features with PDF’s annotation feature. Result: notes on PDFs aren’t captured on input, while notes in the system aren’t included in checked-out files.

Does that sound like “support” to you?

CIO: But PDF is owned by Adobe. What am I supposed to do, lock us into their product/pricing model forever?

I get this one all the time. People are amazed when they learn that it was back in 2008 that PDF become ISO 32000. Since then, PDF has been owned and managed by an international committee of experts from 20 countries and many different business sectors. It’s not owned by Adobe in any way.

The conversation usually ends more or less as follows:

ME: [Having explained that PDF is an ISO standard] …so PDF has so many ISO-standardized capabilities that are clearly relevant to your business applications, it makes sense to check it out, right?

CIO: My developers would just wrinkle their noses. They know web technologies like Perl, Python, HTML/CSS and JavaScript. PDF is like… OMG; where’s the API!

ME: PDF is complex, yes. However, application developers don’t have to get down-and-dirty with the guts of PDF. There are thousands of applications, SDKs, open-source libraries and even Adobe’s own PDF Library to choose from.

It’s really a question of deciding to look at PDF as a toolbox for solving many different types of ECM and ERM challenges rather than as a model for page-rendering.

 Far beyond electronic paper

Once you start to really look at PDF, it’s clearly far more than a page-rendering model.  The format’s features include:

• Archival quality control
• Extensible document and content-level metadata
• Annotations
• Fillable forms
• Security and digital signatures
• Accessibility
• Attached content
• Content re-use
• Watermarking and redaction
• 3D, video and other rich content
• Scripting
• Collation
• and more…

Many vendors have yet to accept that PDF files play a key role in many of their customer’s organizations, and that better use of PDF might lead to new efficiencies and opportunities.

The key word here is: interoperability. PDF is a technical means of capturing, sharing, using, re-using and archiving documents and associated content in a transparent manner that’s fully accessible to every software developer.

Think about what you’d really like to be able to do with your documents. Figure out if PDF includes features that pertain to the functionality you have in mind (it almost certainly does), and could, in fact, take a lot of the workload in the solution.

Then, ask your ECM vendor how their software, which they claim “supports PDF”, fails to support so many of the PDF features that would meet your needs.