Recently in Plug-In SDK Category

Acrobat X SDK is Released and Available for Download

| 6 Comments
Share

The Acrobat X Software Developer Kit (SDK) is a set of tools that help you develop software that interacts with Acrobat technology. The SDK contains header files, type libraries, simple utilities, sample code, and documentation.

Using the Acrobat SDK, you can develop software that integrates with Acrobat and Adobe Reader in several ways:

  • JavaScript — Write scripts, either in an individual PDF document or externally, to extend the functionality of Acrobat or Adobe Reader.
  • Plug-ins — Create plug-ins that are dynamically linked to and extend the functionality of Acrobat or Adobe Reader.
  • Interapplication Communication — Write a separate application process that uses interapplication communication (IAC) to control Acrobat functionality. DDE and OLE are supported on Microsoft® Windows®, and Apple events/AppleScript on Mac OS®. IAC is not available on UNIX®.

The Acrobat SDK provides support for development on both Windows and Apple Mac OS environments.

Read the full Acrobat X SDK Overview
Download the Acrobat X SDK

Acrobat 9.1 SDK Update Released

| 2 Comments
Share

The Navigator SDK for PDF Portfolio Layouts is finally out of beta and is available for download. Samples, updated documentation and other resources are available in the Acrobat 9.1 SDK August 2009 update. You can get it by following the link below.

Share

The Acrobat 9.1 SDK documentation is here!

The Acrobat 9.1 SDK documentation is available in the Acrobat 9.1 SDK download. For offline use, you can download the SDK documentation to your local drive.

Hey! My plug-in won’t load in Adobe Reader

| No Comments
Share

You completed your Integration Key License Agreement for Adobe Reader, you got your certificate, followed all of the steps exactly and your plug-in still won’t load. Why?

Richard Relph, a Senior Computer Scientist at Adobe, has compiled a list of the four common issues that result in a plug-in failing to load and forcing Reader to quit.

1: User error – Signing the plug-in

Signing the plug-in with the tools we have in the field can be an error-prone process. It is absolutely essential that the instructions be followed very carefully. The most common mistake is to "rebuild" instead of "build" the plug-in after computing the signature value, but other mistakes are certainly possible.

2: READER_PLUGIN

The most common problem is a plug-in not being compiled for Reader. Reader does not support the full set of APIs that Acrobat does. The compile-time switch forces the plug-in loading code to NOT fetch certain "HFTs" (an HFT is a table of pointers to APIs) that aren’t available in Reader. If the plug-in loading code (which is a part of the plug-in) wasn’t compiled with READER_PLUGIN, it will attempt to fetch an HFT that Reader doesn’t support, the loading code will return an error, and loading will stop.

3: ACRO_COLOR

Unfortunately, in the samples that ship with the Acrobat SDK for Acrobat 8, we didn’t correctly deal with one particular HFT when READER_PLUGIN is defined. If the developer is attempting to compile or modify a sample we shipped with the Acrobat 8 SDK, besides setting READER_PLUGIN, they will have to modify AcroDspOptions.rsp, which is located in the Samples folder of the SDK. In that file is a /D that assigns a specific version to the ACRO_COLOR HFT. That forces the loading of the HFT, even in the presence of READER_PLUGIN, which will prevent the plug-in from working in Reader. Delete the line in the RSP file.

4: DLL Hell

Some developers have a development machine with Acrobat and Visual Studio and another machine that has just Reader. The problem is that the machine with just Reader doesn’t have all the C Run-time DLLs that are installed "for free" when Visual Studio is installed. The solution to this is to either build the plug-in such that the C Run-time libraries are statically linked in to the plug-in (my preferred solution), or to ensure that the necessary DLLs are loaded on to the target machine with the plug-in. (Yes, this would have to be done as part of the plug-in installation process for end-user machines.) Sometimes this isn’t an issue, because Reader itself installs some of the C Run-time DLLs. Other times, it is because the plug-in was built using a newer or slightly different variation (debug vs. release or multi-threaded vs. single-threaded) of the run-time libraries.

Richard recommends that new Reader developers use the Visual Studio Plug-in Wizard to create a "trivial" Reader plug-in (say with a help item and nothing else). By clicking on the "Reader" check box at the appropriate step in the wizard, problems #2 and #3 and #4 above are avoided. That only leaves problem #1. Once the developer is successful in building a trivial plug-in that works with Reader, especially including the signing process, they have the confidence and experience necessary to move on to signing their own "real" plug-ins and knowing that whatever problems remain aren’t due to any "issues" with the key we’ve sent them or the tools they’ve never used before.

Datalogics releases .NET interface for the Adobe PDF Library

| No Comments
Share

Datalogics, a leading provider of PDF technologies and key channel for Adobe PDF toolkits, announced the availability of a .NET interface for the Adobe PDF Library. This interface will enable application developers to more effectively integrate Adobe’s powerful PDF Library API into their .NET environments, giving them access to a broad range of robust functionality, while taking advantage of the efficiencies and software development features available from the Microsoft® .NET Framework.

Full Press Release
Technical Details