Duff Johnson’s PDF Perspective

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.

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

Changes in Acrobat 8

Acrobat 8 Professional now offers three ways to “bless” a PDF with Extended Rights (”Reader-Enable”):

1. From the Advanced menu, simply select “Enable Usage Rights in Adobe Reader” to bless your PDF with Forms Save, Commenting and Digital Signatures rights. Forms-data import and export rights are also enabled (although undocumented). However, the right to spawn new pages from templates in Reader is unavailable in Acrobat 8 Professional, as is SOAP, or the capacity to bless more than one file at a time. See this post on Thom’s blog and this article by Ted Padova for more specifics.
2. “Distribute form”, available on the Forms menu or task button is a simple wizard that adds Extended Rights within a canned distribution model based on your email client.
3. “Send for Email Review” from the Comments menu or Review & Comment task button calls a wizard which adds Extended Rights for commenting only, disabling any Extended Rights.

Comment

First and foremost, Adobe deserves a lot of praise for taking the risk of moving formerly hyper-expensive “enterprise” functionality right into the desktop mainstream at a “mere” $449 a pop. What’s the catch, right? And for that matter, what’s the point of Adobe’s LiveCycle Reader Extensions Server now?

The “value add” of the Reader Extensions Server has been amended to:

1. Enabling the right of PDF files open in Reader to spawn new pages (as may be called for in on-board javascript)
2. Enabling SOAP rights (connecting PDFs to live content delivered by a webserver)
3. “Blessing” PDFs via the Batch Processor
4. And of course, everyone’s favorite: “because the End User Licence Agreement (EULA) Says So”.

Now… I’m not actually having much luck actually FINDING the EULA text anywhere in the Acrobat documentation post-installation, nor is it up on adobe.com as of this post. So the only chance you have to read it in the short-term is if you pay attention during the customary “click though” moment on installation when you are asked to accept a software licence. This time, don’t just click though, as I did.

In any event. If memory serves, the EULA limits users to either 500 end-users per form, with unlimited “instances” of the forms for each user…. or else distribution to an unknown number of users (ie, posting on a website) with a limit of 500 form-instances collected. How you figure out when you hit these limits is (it seems) up to you.

(…)

You might very well think that, but I couldn’t possibly comment.

The Manifesto Score Card, Article 1

November, 2006, Acrobat Professional 8.0: 8 out of 10.

The lack of the template spawning and SOAP “rights” is a real shame, and it should be possible to batch enable forms. There’s something wrong with the business model when people aren’t being encouraged to use this extraordinary functionality as much as possible. We also need more control over the messages displayed (or not) to the user when they open PDFs with Extended Rights, but these are whines about the way Rights are handled, not the Rights themselves. Even the LiveCycle server product doesn’t include (via the UI, anyhow) enough “controls” over the way Extended Rights actually manifest in PDF.

(An aside, I recently needed Extended Rights on a “kiosk” type project… not to actually allow Reader to Save, but simply to stop the !*&!@#$% warning message about how Reader “couldn’t save this form” from appearing everytime users touched a form-field!)

I also have a caveat on the EULA. Adobe’s real intent is clearly (a) lax and (b) TBD, but what bothers me more is that the idea seems kind of goofy; a barrier to business at best, a missed opportunity on the revenue side (tsk, tsk) at worst.

But that’s for another post.

Nonetheless, the simple fact is that allowing Acrobat 8 Professional to “bless” a PDF, any PDF, with most available Extended Rights, is a marvellous thing. Whole workflows can now blossom in PDF. It’s a $449 bargain based on this feature alone. Reader can Save! If you’ve bothered to read this far, you know what that means.

More Articles to follow over the next few months.

The single most important feature of Acrobat Professional 8 is a dramatic expansion in the Reader Extensions that Acrobat Professional may apply to PDF files, bestowing new “Extended Rights”. Of these, the most important such “Right” is commonly known as “Reader Save”. Within the new End User Licence Agreement (EULA) and certain other technical limitations, Acrobat Professional 8 obviates the need for expensive servers, programmatic chicanery or 3rd party products to deploy this key feature for end-users.

Simply put, Reader Save allows an Acrobat Pro user to “bless” a PDF such that form-fields may be completed and then saved by any user with the free Adobe Reader. This facility is a desirable quality for almost any fillable form, and in many cases, it is simply essential in many of the form workflows actually operating in the real world.

Before Acrobat 8, the only way to get this feature into a PDF was via Adobe’s Reader Extensions Server (ARES), five-figure “enterprise” software sold exclusively through Adobe’s direct-sales bureaucracy. ARES remains a product in Adobe’s LiveCycle lineup - more on that later.

In July, 2006, I introduced the Extended Rights Manifesto; essentially, a set of checkpoints for assessing the implementation of Reader Extensions in Adobe’s PDF management software. The idea was to offer encouragement and guidance to Adobe Systems as they pondered their strategy for moving Reader Extensions to Acrobat Professional.

In forthcoming posts, I’m going to go through the Articles of the Manifesto one by one, and “score” Adobe on the new playing field they’ve created with Acrobat 8. At the same time, we’ll doubtless think of some revisions to the Manifesto, in fact, we’ll need a whole NEW Manifesto just to keep up. Stay tuned! Along the way, please feel free to let me know YOUR thoughts on Extended Rights as well!

With Acrobat 8, everything changes

A PDF form enabled for Reader Save in Acrobat 8 Professional may
now be completed and SAVED using the free Adobe Reader!

From the introduction of forms technology to PDF nine years ago until today, users with the free Adobe Reader could certainly fill out and print a PDF form (if, in fact, it included form-fields), or submit the form to a server, but that was the limit. Could they save their work along the way? No. Could they fill out part of a form, and pass it to a coworker to check over and complete? Nope.

PDF forms offer an easy yet sophisticated way to move existing business-processes from paper to the computer without losing the connection with paper workflows. This capacity was intentionally hobbled in the free Adobe Reader, sending most users to the printer once they’d filled-out a form. Quite apart from end-user frustration, the limitation effectively precluded implementation of PDF forms in many distributed applications where end-users could not be expected to own Adobe’s $300 Acrobat Standard software.

PDF forms exploded nonetheless. From the IRS to the smallest non-profit, organizations everywhere found a myriad ways to to use PDF forms, Reader Save or no. The ability to add typed text to a form that would faithfully reproduce itself when printed was an obvious winner.

Naturally, almost as soon as the forms capability was introduced to PDF in Acrobat, users and third-party developers alike began asking for (nay, demanding!) the ability to save completed forms to the user’s own computer using the free Reader. The absence of the feature was (rightly) regarded as the single biggest barrier to wholesale implementation of PDF forms. Adobe Systems understood this, but also understood that Reader Save had major revenue potential, and thus were in no hurry to give it away for free.

After an abortive attempt at a low-cost “Reader + Save” product called Acrobat Approval, (junked to howls of protest from 3rd party PDF developers), Adobe Systems faced the demand for “Reader Save” capability with the development of the Adobe LiveCycle Reader Extensions Server (ARES), the basic purpose of which is to “bless” PDF files with various “extended rights” - including the ability to be saved with Adobe Reader.

ARES remains very, very expensive, and the typical customer is a large corporation or government agency with a major forms headache and a server software budget in the high five figures. The lack of a affordable Reader Save solution helped foster the so-called “Acrobat Alternatives”, including ARTS Nitro PDF, Nuance’s PDF Converter and Global Graphics’ JAWS PDF Editor. Besides replicating many of the most popular functions in Adobe Acrobat Standard and Professional, these lower-priced products allow users to fill and SAVE a form right there on their own computer.

And then, late last year came word of Microsoft’s foray into PDF creation. Ouch. So what does Adobe do? It was time for the heavy artillery.

Adobe’s Response

The Acrobat Alternatives and Microsoft’s PDF software exist only because Adobe Systems elected to publish the PDF Reference. This move made it possible for any sufficiently competent software developer to create and edit PDF files without any Adobe software. This was, in a sense, a calculated risk. The move could spawn competitors to Acrobat, but on the other hand, a world awash in PDF (from whatever source) could only be a good thing.

What Adobe did NOT give away, of course, is the code for the free Adobe Reader. This ubiquitous software, installed on hundreds of millions of computers worldwide, is Adobe’s “special sauce”, for only they can build features into Reader that PDF files can unlock.

Even with all of the advanced capabilities in Acrobat 7, most people still buy the software because it can make PDFs, period. The “higher” capabilities of the PDF format barely register for most developers and decision-makers, and are rarely utilized.

Adobe had to change that, or risk increasing peril to the Acrobat franchise. With the announcement of Acrobat 8, Adobe can (and I believe, will) move beyond the perception that “Acrobat is for making PDFs, Reader is for Viewing PDFs”. The ability to add Reader Save capabilities to PDF files creates a compelling reason to purchase Adobe’s own desktop software for creating and managing PDF files - Adobe Acrobat and Acrobat Professional - before any others. Awareness, interest in and adoption of PDF as an electronic document in its own right, not merely as a conveyance for a consistent printout, is about to take off.

To give you an idea of the way I feel about Reader Extensions…

I was visiting a client this week. One of their graphic designers raises Ball Pythons, and (on request) brought one into the office during my visit. We got kind of cozy.

Anyhow… the POINT I’m trying to make is that the Extended Rights Manifesto has been updated with Article 10. To save you a click, here it is:

Article 10

Separate “form” rights from “save” rights. PDF forms are often used for document applications rather than as forms per se, as in CD-ROM interfaces, electronic brochures, and so on. These applications may require Extended Rights to import FDFs (for example), but do not require the ability to save a form. For these purposes, Acrobat Professional should be able to bestow form rights on a PDF without limitation or reservation. With these “pdf as application” rights applied, the default form-related warnings to the user when opening or closing the PDF would not occur.

In this way, it would become very easy to develop “application” PDFs using the full suite of forms functionality without interfering with a “real” forms oriented business-model for Extended Rights.

I’ve received sufficient interest in the idea of a “Manifesto for Reader Extensions” that I realized I needed to (a) swap the nomenclature to “Extended Rights”, and (b) make a “proper” page for the idea. Here it is. Please feel free to email me your comments and suggestions. If your suggestion is adopted, we’ll add your name (only if you wish) to the Contributors list!

The name change idea (thanks, Max Wyss) was a “duh” as soon as I heard the suggestion. Not auspicious, I suppose, such evidence of mental clutter. Moving on…

Purpose

This post is intended as a simple sketch of views on the “ideal” Reader Extensions business model. Suggestions for amendments or additions to the Manifesto are encouraged! If this post threatens to become a serious document, I’ll move it to it’s own page for further development.

Background

For these purposes, “Reader Extensions” amount to a “switch” within a PDF. When the switch is “flipped”, users with the free Adobe Reader may not only fill out a PDF form, they may SAVE a filled-out copy on their local computer. This single feature has profound implications for the Acrobat/LC business models. Enabling PDF forms for “ReaderSave” is one of the most powerful and horizontally applicable features in Adobe’s arsenal.

Reader Extensions: A Manifesto

1) Acrobat Pro should be able to “bless” PDF files with Reader Extensions (RE).

2) Acrobat Pro and Adobe Reader Extensions Server (ARES) should always complement each other, and never compete.

3) The pathway from Acrobat-driven RE LifeCycle-driven RE should be SMOOTH. Almost any type of application requirement should be easy to accomdate within either model.

4) Scaling from Acrobat Pro-driven RE to LC-driven RE should NEVER imply operational risk to the application. Users should never have to endure a “hard stop” to their workflow simply because (for example) orders peaked in the third quarter! “Crash” installations of ARES to overcome a limitation in Acrobat Pro won’t be good for anyone.

5) The limits on Acrobat Pro’s ability to add core Reader Extensions features should themselves be EASILY extensible via a simple pay-as-you-need-it scheme. For example, if Acrobat Pro were to have the ability to make 250 instances of a form “reader-savable”, then each licenced user should be able to purchase (without ARES) the ability to make the same form savable for 500, 1,000, 10,000 or 25,000 instances at additional cost, using a simple online payment method.

6) RE can be monetized at desktop and server levels alike, and the benefits of each should complement the respective solutions.