For a few years now Adobe has been telling 3rd party developers that the ADM (Adobe Dialog Manager) will be discontinued, and that existing plug-ins may have to be ported to something else. If I remember correctly, this started with Acrobat 7 or 8, but back then it was a soft threat – everything still worked, and there wasn’t much incentive to start porting plug-ins. However, with the release of the Acrobat 9 SDK the ADM related header files were gone, but ADM based plug-ins were still working (at least some of them).

The removal of the header files does send a strong signal, but what was an even stronger signal for me was that one of the ADM based plug-in I was working on was no longer working correctly on some versions of Windows.

As far as Adobe is concerned, ADM is no longer supported – that means there won’t be any bug fixes for it, but the plug-in has to work with Acrobat 9 on any Windows system that’s supported by Acrobat 9. So, what is a developer to do in such a situation?

Adobe does not give us much guidance in what to chose as a replacement for ADM. The most obvious choice is to stick with the native UI framework that comes with the operating system, but the advantage of ADM was that one could write UI code that would run in both Windows and Mac plug-ins. One of the sample plug-ins – wxPlugin – that comes with the Acrobat SDK is based on wxWidgets. To me that was a pretty strong hint that wxWidgets would be a good choice…

However, even though the Mac version of the SDK does come with the wxPlugin code and even contains a XCode project file, it does not compile. After some work, trying to come up with a combination of wxWidget configuration options and wxPlugin project settings, I was able to create an Acrobat plug-in that worked.

In order to “fix” the Mac’s version of the wxPlugin I first had to compile wxWidgets. Use the following configure command line to create the static wxWidget libraries that can be linked with the project:

configure CC=gcc-4.0 CXX=g++-4.0 LD=g++-4.0 --enable-universal_binary \
--disable-shared --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk \
--with-mmacosx-version-min=10.4 --enable-debug

Just install the libraries and include files according to the instructions provided by Adobe.

A closer inspection of the plug-in code then revealed that the part that actually did anything was commented out for the Mac with #ifndef MAC_PLATFORM statements, so I removed those and the last thing to do was to remove the reference to the libexpat library – it is provided by the operating system and does not have to be provided by wxWidgets.

With a working environment on the Mac, wxWidgets is a viable alternative for ADM for either new Acrobat plug-ins, or existing plug-ins that need to be modified to make them compatible with the current version of Acrobat.

If your Acrobat plug-ins are still using ADM, now would be a good time to think about what to do about that… If you need any help, let me know.

If you’ve seen my resume – or talked to me lately, you know that I create Acrobat plug-ins for a living. When people hear that, they usually think something like “Don’t forget to pick up the dry cleaning” or “I need to bring my cat to the vet for the rabies shot”… Yes, I understand, this may not be the most exciting topic, but probably only because you don’t know enough about what these “plug-ins” are, so let me explain.

 

Adobe Acrobat is a very powerful tool, more powerful that most users actually realize. I wont go into any details about how powerful exactly – at least not today. Lets just say that it has something for everybody. However, you may need something in addition to what Adobe provides, something that still is in the general area of PDF. Adobe may not have considered your needs because either the target market for “your” feature is too small, or to far out there… Or you are so far ahead of everybody else that they have not even thought about that feature yet.

Adobe did however do a very interesting thing: They created an interface that allows 3rd party developers to create solutions based on Adobe Acrobat – using plug-ins. It is a very powerful interface, and hence not something that you can pick up in an afternoon. There are several thousand pages of API documentation that one needs to understand before a plug-in should be written.

A plug-in is – from a technical point of view – a module or library that gets loaded dynamically at runtime. Acrobat will scan it’s plug-ins directory and will load any modules it finds. Once loaded, such a plug-in can extend Acrobat by e.g. adding menu items, toolbuttons, or event handlers (e.g. a function that gets executed whenever a documents gets loaded).

 

Interestingly enough, the plug-ins directory of a fresh Adobe Acrobat installation is not empty… A lot of Acrobat’s functionality is actually implemented as plug-ins. You can verify that on a Windows system by temporarily disabling all plug-ins by holding down the Shift key when bringing up Acrobat. That will load the application without any plug-ins. When you compare the toolbar or the menu bar with a fully loaded application, you’ll see what portion of the Acrobat core functionality is actually implemented in plug-ins.

The plug-in interface has different abstraction levels (COS, PDE, AV, …). If there is enough interest, I will provide information about how to navigate that API, and how to structure a plug-in.

The Acrobat SDK is available for free from Adobe’s Acrobat Development Center.

Here are a few examples of commercially available plug-ins that I’ve used:

• Enfocus PitStop Professional:
  This is a preflight tool.
• Quite Imposing Plus:
  The best PDF based imposition tool that I am aware of.
• Enfocus Browser:
  Allows to review and change the internal structure of a PDF file.