Duff Johnson’s PDF Perspective

I’ve been working on “live” files using Acrobat 8 Professional for some time now, so my initial reactions to the latest version of Acrobat are a little more seasoned.

I had this in mind during a recent interview for MacAddict magazine.

Since I went on at greater length than they could possibly print, I thought I would inflict the balance of my words on you, the helpess RSS robots (and occasional human) monitoring this Blog.

> What is your overall opinion of Acrobat 8?

The vast majority of desktop PDF users still think of Acrobat and PDF for basic create/view/print applications - if, that is, they don’t think of them collectively as just “Adobe”. With XPS looming and competition stiffening, Acrobat 8 represents a serious effort on Adobe’s part to awaken end-users to PDF’s higher uses. The redesign is new-user friendly, yet includes some neat tricks for power users that help to smooth out certain grumbles. There’s not a lot that’s strictly speaking “new” in Acrobat 8, but there are a lot of very powerful refinements, and some key additions.

> What are the most important new features for the average user? (Whomever that is.)

Oddly enough, it’s very hard to say - testimony to the very breadth and depth of the toolkit. The very first Acrobat users thought it was a prepress tool. For others, it was (and is!) a document assembly and distribution tool, or a scanning tool, or a platform for developing interactive PDF forms, or archiving documents, or commenting. There are many other equally dissimilar tasks in which some aspect of Acrobat is considered vital. “Swiss army knife” remains about the fairest overall description.

Perhaps the most important single change is the effort Adobe has put into helping newer users get more out of Acrobat than just the very basics. In Acrobat 8 most (but not all) of the tools got either a little or a lot better, depending mainly on what you need and how cleverly you use them.

That said, from my “knowledge worker” perspective, the single biggest new feature is the ability to “bless” PDFs using Acrobat Professional so the free Reader can save a user-filled form before printing or submitting it to a server.

> What are the most important new features for the vertical markets (e.g., government, manufacturing, legal, etc.) Does anything stand out in this regard?

Allowing Reader to save a form stands out in any context. Every industry uses forms, and extended this capability to Reader is BIG, without a doubt.

The legal community seems excited about redaction and bates-numbering (which surprised me, since excellent PDF redaction AND bates-numbering software from Appligent has been around for years), but government, publishers and others who want to make their PDF files more accessible (or PDF/A-1A compliant) won’t find substantially improved tagging tools in Acrobat 8.0.

Unlike Adobe, I don’t really believe traditional verticals are especially meaningful when it comes to PDF and Acrobat. There are many seemingly subtle enhancements in Acrobat 8 that offer immense opportunity for streamlining regular and ad-hoc work processes in many verticals. That’s because these are really document processes, not vertical processes.

Take the upgraded Combine Documents tool for example. Notice that this slick, easy tool now allows users to select and convert individual pages from different sources, preview the results and save that overall configuration for reuse. Workgroups large and small can continue to update documents individually, simply pushing the “easy button” in Acrobat 8 to combine all efforts together at the end of the day. Very cool. What vertical needs that? Any of them could really use it, and it’s only one such feature.

> Are there any often-requested features that aren’t in Acrobat 8? (i.e., What are the key missing pieces?)

While Extended Rights via Acrobat are great, the way they are implemented (and limited) in the EULA (End User License Agreement) makes little sense. Adobe has set a legal, financial and/or logistical cliff at the 500 user or 500 forms mark, depending. If LiveCycle is to meet the potential, Adobe needs to put (a lot) more attention into smoothing the transition from desktop to server-orientation in this area.

I was also quite disappointed to see very little improvement to the tagging tools. Ensuring that content semantics may be extracted from the document is a key aspect of making documents usable by those who must use assistive technologies to read. From accessibility to PDF/A to content reuse, automation and search-engine optimization, meaningful semantic tagging isn’t going away as an issue and there are a lot of corollary benefits to getting it right. Adobe needs to get going here.

I have to also say that it is well PAST high time that Adobe upgraded the JavaScript editor and made the power of JavaScript in PDF more accessible for the newer user, and less frustrating for the leathery Acrobat javascript gurus who can really make PDFs fly.

> Is Acrobat 8 a good value for new purchasers and upgraders?

Acrobat 8 Professional is an especially good value for new purchasers. While the application as a whole is very wide and deep, it is now laid out in a way that is fundamentally more approachable for new users. The new Combine Documents feature alone, if carefully studied and implemented, could deliver dramatic document-assembly benefits to distributed teams in almost every desk-bound organization.

Upgraders will find many improvements, even if the tonka-toy icons, unnecessary and lurid alerts and uber-prominent navigational panel cause distress. Adobe has yet to decide whether (or how) to trust Acrobat javascripters, putting a drag on the uptake of PDF in advanced forms and kiosk applications.

When I first tell someone that blind people can read PDF files, I often get a slightly puzzled expression. Sighted people sometimes appear to assume that the blind can’t read; that maybe somehow blind professors and programmers and lawyers are born, not taught.

I digress. The fact is that blind and other disabled individuals can not only read PDF files, but Word files, web pages and other electronic content using “screen reader”, or other types of “assistive” software or hardware, depending on their disability.

Beyond the simplest of documents, what is required in order to be considered “accessible”, document contents must be structured such that tables, images, footnotes and so on are correctly identified to the user. Without structure, documents are just a heap of words - or letters, if you prefer to assume away the structure that binds the letters and words together into paragraphs.

Sighted users get to “cheat” by gaining clues about tables, lists and so on from the page layout. Those who must use alternative reading methods to read the same document often can’t access this presentational information. They are dependant on either the structure (or lack thereof) in the document, or else the capacity of their reading software to correctly impute the structure based on a programmatic examination of the page.

Section 508 requires that some minimal amount of structure information must be present in order for a document to be considered compliant with the regulation.

Although PDF content is a staple on virtually all government and corporate websites, actual Section 508 compliance assessment and subsequent correction of PDF content remains poor in federal and state government, to say nothing of the corporate world. There are three principal reasons for this.

1. Generally speaking, authors of PDF documents (who aren’t web-content managers) have no idea whatsoever about ensuring their document is accessible. Web content managers, on the other hand, usually know something about accessibility, although they generally focus only HTML.
2. With existing technology, PDF content is far less amenable to automated or even semi-automated accessibility evaluation and correction as compared to content that’s delivered as tagged text (HTML, XML… all the “MLs”). There are a variety of reasons for this, but trust me, it’s true.
3. While PDFs are unambiguously “web-content”, web-content managers nonetheless tend to disregard PDFs, simply because “all they ever do” with a PDF is link to it, or facilitate the creation or emailing of a PDF. Regarding the contents of the PDF and the accessibility thereof, they generally don’t have a clue. PDF is thus the “blind spot” for web-content managers.

Without a doubt, the tools for evaluating and correcting PDF tagging to ensure Section 508 compliance need more work. Strong third-party options for PDF tagging such as NetCentric’s CommonLook Acrobat plugin are emerging.  Adobe’s Acrobat Professional 8.0 itself got a rather modest upgrade in the accessibility department - more on that in some other post. ABBYY’s FineReader and Nuance’s OmniPage OCR software are providing new tagging options for PDFs that begin life in a scanner.

The real problem at this juncture is not the developers - after all, they respond to the demand, and demand is coming, thanks in part to the new Target lawsuit. For the moment, we can safely note that it is the web-content managers who have yet to take on board what accessibility standards really mean to them, whether Section 508 or any other mandate. Section 508 doesn’t exactly set a high bar, being somewhere south of WCAG 1.0.

Reports, documentation, manuals, presentations… content needs to be tagged with semantic structure to comply with Section 508. It’s not just HTML and web pages, this applies to Word, Excel, Powerpoint… and of course, to PDF as well. Content tagging should go well beyond current Section 508 standards if a document is to be considered authentically accessible to those who must use assistive technology to read. End-users MUST learn how to structure documents correctly from the outset.

Launching the revolution in structured content is the next frontier. Let’s get on it!

I was sufficiently intrigued by the Adobe Document Center to put it to the test with a real document distributed to a reasonably savvy group of people.

I’m one of those people who finds Flash more than a little overused. Once the initial buzz from the soft-focus feel of the all-Flash UI wore off, the Document Center did nothing to dispel this view.

Certainly, the process of adding new Policies and then applying them to documents was very easy. The Document Center doesn’t make it especially clear that applying Policies to documents is conducted from within Acrobat, which it is.  Create a Policy, go back to Acrobat, open your document and navigate to Advanced -> Security -> Manage Security Policies, login using your Adobe ID, select your Policy and save.  That’s it!

Less easy, as I went through version after version of my document, was retaining any meaningful picture of actual usage over time, one of the great Policy Server Promises.  I couldn’t delete revoked documents from the UI, or consolidate their statistics - perhaps that’s just a reporting issue, but it’s significant.  I also couldn’t group users, and I could never tell if or when the interface actually updated, and resorted to logging out and back in, which always seemed to do the trick. 

So, it’s a freebie interface for a freebie demo application, so I guess that’s OK.  I sure would hate to have to use it as a going concern, though.  Subtle hint.

I also found that my document recipients (and they are savvy, no kidding) were in a surprising number of cases quite stumped when confronted with a Policy Server protected document.  Part of this was due to a degree of reticence (or forgetfulness) in loyally signing up for Adobe IDs as is necessary for Adobe Document Center-protected documents.  Part of the problem was clearly also the cumbersome, Flash-heavy (why?!?) signup screen, which sapped enthusiasm further in at least two cases.  Worst, a disturbing number of reports (ie, more than 1) attested to the files consistently “crashing Acrobat”, which certainly wasn’t what anyone wants to hear.

So, I guess I have to report that thus far I’m not totally charmed, there are some definite rough-spots.  The Policy Server is undeniably an extraordinary concept, and I’d like to see much more of it. I certainly proved to my own satisfaction that I could flip a switch in Boston and watch my chosen file go “dark” all over the world, almost instantly, from Manila to Moscow.  For a second, lightning crackled between my fingertips as well.

Here’s hoping that Adobe will leave it in place past the end of the new year, or else limit freebie users to 2 protected documents at any given time… or something of the sort. Let the people kick the tires!

The ability to issue a truly embargoed document and then seamlessly (to prepared users, in any event) update it while simultaneously and effectively deleting all prior distributed copies is, quite simply, MAGIC.  Policy Server could be a real smash-hit if the execution, marketing and sales can be made to match, or even approach, the power of this product concept.

Those who read my (too) frequent tirades knows that Adobe has to do a lot to impress me. In that spirit, I am VERY happy to report that Adobe has (finally) done something really smart in marketing a LiveCycle product; they’ve put a Policy Server online for anyone and everyone to try out at no charge - through the end of 2006, at least.

Simply put, Adobe’s new Document Center allows you to secure PDF (and now .doc and .xls!) files in meaningful and really useful ways. No dinky, readily cracked passwords here! With a couple of simple clicks at the Document Center, you can:

• Ensure only specific recipients can view a file (based on verified email address)
• Restrict printing or copying file contents, even with “authorized” recipients
• Set specific time-periods where access is or isn’t permitted
• Allow documents to work offline for a specific time-period before “calling home” to log offline access
• Cause PDF files to “embargo” themselves until a specific date and time
• Cause every copy of a document to “expire”, and (optionally) prompt the user to retrieve an updated file.

You’ll need Adobe Acrobat Standard or Professional 7.05 or higher to access the Adobe Document Center, but users with Adobe Reader 7.0x or higher will be able to view your encrypted PDFs - if you’ve specifically allowed them to do so. You’ll also need a (free) Adobe ID, which is reasonably painless. NOTE: Your files are NOT uploaded to Adobe in the encryption process, so you need not worry that Adobe will suddenly know your secrets.

So, get over to dc.adobe.com at some point in the very near future. I guarantee you’ll be impressed as well. You may even be thinking “Wow, this is kind of crude, but now that I’ve seen it, I wonder if I could live without it? I suspect that’s the idea.

The Adobe Document Center is FREE right now, for a limited time only, at dc.adobe.com.

For those who do more with heavy technical reference tomes than merely prop open the window, you’ll be interested to know of Adobe’s latest opus; the (now) 30.9 MB, 1,310 page PDF Reference (and accompanying Errata and Redaction Addendum). 

When Adobe Systems originally decided to publish the PDF Reference, the document that describes in all significant detail the innards of PDF, was fairly manageable in scope.  With a few months dedicated effort, a reasonably competent development team could (in theory) build software to make simple PDFs every bit as good as PDFs made with Adobe’s own code.

Since then, many third-party developers have tried their hand at PDF creation, manipulation and management with a wide variety of results. The challenge of “keeping up with Adobe” has grown massively since initial publication of the Reference, and most 3rd party developers don’t try - many of the newer features in PDF are simply unnecessary for their applications. Thus far, anyhow, Adobe has seen itself honor-bound to respect PDF files meeting a very broad definition of “valid”, no matter how old (or creaky) they may be.

The PDF Reference 1.7, the “Acrobat 8 update”, is now available for free download from Adobe’s PDF Technology Center.

For those who yearn for maximum PDF power, Adobe has posted essential new reading in the latest JavaScript Reference for Acrobat 8.

As the brag states, Acrobat JavaScript “…implements objects, methods, and properties that enable you to manipulate PDF files, produce database-driven PDF files, modify the appearance of PDF files, and much more. You can tie Acrobat JavaScript code to a specific PDF document, a page, field, or button within that document, or a field or button within the PDF file, and even to a user action.”

As my colleague Thom has noted, Acrobat Javascript now supports ECMA-357. Now XML may occur natively in Acrobat JavaScript.

Those who develop with Acrobat, especially those who have used menu-item commands in their applications, will want to pay SPECIAL attention to this new version of the Reference. Already, some poor souls are finding out that things have changed in Acrobat 8, not necessarily to their advantage.

Those familiar with Acrobat JavaScript are strongly encouraged to begin by skipping to page 733, “New Features and Changes”.

This post is part of a series based on the “Extended Rights Manifesto“. See this post for some context.

To monetize the gap between the free Reader and for-sale desktop software, Adobe developed the LiveCycle Reader Extensions Server. This software “blesses” PDFs with “Reader Extensions” that can switch on latent capabilities in Reader, allowing users to save the contents of a form, import or export form data and add annotations, among other powerful functions.

Whatever you may think of this arrangement, the Reader Extensions Server is sold as “enterprise-class,” with price to match.

Adobe has been easing the Reader Extensions concept into the Acrobat Professional desktop software business for a few years now. This software costs a (mere) $449, but until Acrobat Professional 8, was incapable of “blessing” PDF documents for “Reader Save”.

The ability to add the Reader Save Extension to a PDF is the key new feature of Acrobat Professional 8. But was the move consistent with Adobe’s server software business model? Is there a unified strategy, and if so, what is it?

The answer may (or may not) emerge over the course of this series of posts. However, what does seem clear is that the desktop and server products in the current model don’t complement each other in any direct way. Yes, there’s an indirect connection via a notional increase in exposure for the server product, but it’s all very understated and subtle, if it’s even intended at all.

The Acrobat EULA (End User Licence Agreement) advises users of the “legal limits” of their usage of Extensions added via Acrobat 8 - in other words, the EULA limits imply the need to “step up” to Reader Extensions Server, or else your application will fall off a legal cliff. (Fullest Disclosure: The author is NOT an attorney, and this is NOT a legal opinion. The word “cliff” is an editorialism, and does not appear in the EULA).

Oddly, while Acrobat is replete with warnings and dialogs on almost every other occasion, the only place you’ll find the EULA discussed is in the 7,000 word document itself, buried in your Program Files folders (and posted here, as a public service). You are looking for Section 14.13.3.

Apart from the EULA, the other method chosen to “communicate” the limitations of Acrobat’s Reader Extensions (and therefore, one assumes, the benefits of the server product) was simply to leave out many of the more sophisticated Extensions in Acrobat 8. While Reader Save and FDF import and export are supported, for example, spawning new pages from templates, importing XML/XDP to XFA forms and SOAP are not.

Adobe’s logic seems to be that if your form is “fancy” on some metric that includes the use of specific Extensions, then your application is “Extensions Server only”. Want to build it up first, then buy the Extensions Server if business conditions avail it? Sorry buddy, you’re out of luck.

OK, I understand the need (desire, at any rate) not to undercut the Reader Extensions Server product by just throwing EVERYTHING into Acrobat. What I don’t understand is the way Adobe chose to go about it.

Part of the problem is the basic organization of the LiveCycle products. The Reader Extensions Server offers no value other than the granting of Extensions - indeed, it’s not really a server-type product at all. Rather than attempting to “trap” revenue in this specific product, Adobe should be leveraging Extensions themselves to draw desktop-product users towards the rest of the LiveCycle technologies, Policy Server in particular, where the need for a server in the loop is clear-cut.

The Acrobat 8 EULA as it stands is unworkable, even for the honest citizen, and is thus ill-considered on that basis alone. Adobe should have offered a more creative and gradual mechanism, with any and all Reader Extensions available via Acrobat, perhaps using a smooth web-based licencing model, (as mentioned in the Manifesto, Article 5).

Just as with PDF itself, the focus with Reader Extensions for PDF should be on helping hundreds of thousands of forms-developers (and others) to know and love the concept for any purpose that suits them with a minimum of interference. It was a good business strategy for Acrobat, it will be a good one for many of the Reader Extensions as well, when Adobe finally gets around to implementing it.

The Manifesto Score Card, Article 2

“Acrobat Pro and Adobe’s LiveCycle Reader Extensions Server should always complement each other, and never compete.“

December, 2006, Acrobat Professional 8.0: 3 out of 10.

These two products now not only compete, but the competition isn’t even very “friendly”. There are no guideposts to implementation, not even a simple comparison matrix. There’s little evidence that the server and desktop products have been considered in complementary terms at all. Instead it is simply left to the (often unsuspecting) implementer to bump into the limitations (both operational and legal) in Acrobat, doubtless in many cases long after x, y or z result has been promised to the boss.

Not the way to win friends and influence people.