Thoughts on Adobe Acrobat Plug-in Development

Kas Thomas

October 17, 2000

Advertisement
Advertisement

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.