Thoughts on Adobe Acrobat Plug-in Development

Consider the following facts about plug-in development:

Fact No. 1: Plug-ins are compiled, not interpreted.

There is no way to do a plug-in via ‘scripting’ languages. To write a plug-in
requires that you use C or C++. On the Mac, that means Metrowerks Code Warrior C. On
Windows, it means Visual C++ and a 32-bit environment. What it means in the end is
that your plug-in will run on one machine but not another. If the plug-in is
trivially simple, with no user interface to speak of, you MAY be able to port the
code easily to another platform. But don’t count on it.

Fact No. 2: The Acrobat SDK is daunting in size and
complexity.

The Acrobat Software Developer’s Kit expands to around 37 megs in size.
Around two-thirds of it is documentation. You won’t need to read every single one of
the 40 or so docfiles that come with the SDK, but you definitely will need to
spend some time reading the half dozen most important ones, including the 2,795-page
Core API Reference.

Fact No. 3: Writing plug-ins for Acrobat is one thing;
writing plug-ins for Reader is another thing entirely.

To get Reader to load your plug-in, you will need to obtain an Acrobat Reader
Integration Key. Getting a key is a matter of filling out the Acrobat Reader
Integration Key License Agreement (available on Adobe’s developer web site), signing
it, and submitting it, along with a $100 payment (in the form of credit card only),
to Adobe’s Klamath Falls, Oregon group (which administers the developer programs).
When you sign the agreement, you are agreeing to some fairly serious limitations as
to what you will and won’t try to do in your plug-in.

Specifically, you are agreeing never to include any of the following kinds of
functionality in your Reader plug-in:

  • Anything that would allow Reader to permanently modify, save, or
    write files, including PDF files, annotations for PDF files, form data, etc.
    Included in this is any functionality that would enable another process (on
    a server, say) to save such data.
  • Anything that opens encrypted documents by bypassing normal security
    measures.
  • Anything that would display a PDF file in the window of another
    application.
  • Accepting navigational commands from an application other than Reader
    itself.
  • Making use of any function call in the Forms HFT (host function
    table).
  • Implementing a replacement file system for Reader.
  • Anything that would remove the menu item that calls up the ‘About’
    screen for Reader. In other words, forget about making permanent changes to files (or doing
    disk writes) in a Reader plug-in. The whole idea is that Reader must remain read-
    only. (Otherwise it wouldn’t be called Reader!)

Fact No. 4: What you intend to accomplish may not even be
possible with a plug-in, in the first place.

Consider carefully whatever it is you intend to do via a plug-in. In a surprising
number of cases, you’ll find either that you can do what you need to do via IAC
scripting (inter-app communication via AppleScript
or the equivalent), or maybe even via JavaScript; or, you may find that it’s not
even possible to accomplish the desired goal at all, with a plug-in.

An example of the latter became evident when a client approached me with a need
for ‘help with a plug-in.’ The purpose of the proposed plug-in was to implement a
new image-compression method for Acrobat (to supplement JPEG, CCITT, Flate, and
LZW).

The client was quite shocked when I told him there was no way to do that in a
plug-in; at least, not using Adobe library routines. The plug-in API (app
programming interface) does not expose this kind of functionality. You can implement
a new security handler, but not a new image filter. Adobe purposely kept the latter
type of functionality under wraps, so as not to encourage people to create non-
interoperable PDF files.

There are other examples of ‘impossible tasks’ for a plug-in. E.g., if you want
to change the default order in which various objects are drawn, apply a different
kind of antialiasing, or improve the blitting performance of Acrobat…good luck!
There are no hooks to these sorts of functionality. If you want to change the anti-
aliasing, your best bet is to implement a custom WDEF (on Macintosh) or maybe a
system extension. (I’ve always felt there should be a way to adjust gamma on a
window-by-window basis in Mac apps. But I’ve been too lazy to attempt a utility for
doing this.)

I’d like to see Acrobat use a crisper AA algorithm for pages with serifed
typefaces and a less-crisp AA routine for Helvetica pages. (Actually, as I say, this
may be best thought of as a gamma-adjustment problem rather than an AA problem…)
But guess what? This would be difficult, at best, to do in a plug-in.

It turns out LOTS of things are difficult (or impossible) to do in a plug-in.
Plug-ins aren’t the developmental panacea you may have thought they were.

You May Also Like

About the Author: Kas Thomas

Leave a Reply