PageMaker Plug-Ins Overview

Welcome to the PageMaker plug-ins Software Development Kit. This package provides documentation and sample code to help you write plug-ins for PageMaker 7.0.

The PageMaker plug-ins mechanism enables third-party developers and users to add to the capabilities of Adobe PageMaker. Using a command and query language to communicate with PageMaker, plug-ins can perform any action a user might do with the keyboard or mouse, extract information about the content and structure of publications, and more. New as of PageMaker 6.5, the component interface API allows you to create plug-ins that provide even more features and power than before.

What is a plug-in?

There are three ways to automate, or control, the PageMaker application:

Of these three, plug-ins are the most efficient. In addition, plug-ins can also customize PageMaker's behavior in ways that cannot be done through IAC or scripting. For example, with a plug-in you can create floating palettes that add new controls (and new functionality) for users.

What can plug-ins do?

The range of possible plug-ins is vast. Plug-ins can:

What plug-ins can't do

The plug-in mechanism is a great tool, allowing you, the developer a lot of flexibility in customizing PageMaker, but there are limitations to the plug-in architecture. While you can replace the functionality behind a menu item (see the OpenCopy example), you cannot move or delete any of the PageMaker menus, and with the exception of the Plug-ins and Plug-in Palettes menus, you cannot add items to any of the menus. You also cannot alter or remove the existing PageMaker palettes; nor can you alter or remove any of the API functions. However, using the Adobe PageMaker 7.0 API, you can provide valuable, capability enhancing plug-ins for PageMaker users.

Who will use plug-ins?

Plug-ins are attractive to all sectors of the desk-top publishing market-both Macintosh and PC, high- and low-end. Numerous plug-ins are appropriate for a broad range of users, while others fulfill specific market needs in such areas as graphic arts, business communication, technical and scientific research, academia, training, multi-user environments, and, of course, the various types of publishing (magazine, newspaper, database, scientific, government, and catalog, among others).

How do plug-ins interact with PageMaker?

All plug-ins communicate with PageMaker through the plug-in interface manager. Applications using the IAC channel (Apple Events or DDE) use commands and queries to automate PageMaker. In addition to using commands and queries, plug-ins that exist as loadable modules are also able to acquire interfaces pointers, which allow the plug-in to use PageMaker's interfaces directly.

The interface manager directs commands and queries to either the parser, or if in the binary format (more about this later), directly to the appropriate action or information routines. As shown, the action routines are the same routines PageMaker uses when you use the mouse or keyboard.

Binary query responses are sent back to the interface manager, which in turn sends the responses to the plug-in. Text query responses are sent through the parser before being sent to the interface manager.

How complex is the PageMaker plug-ins mechanism?

No knowledge of the PageMaker internals needed

You do not need to know anything about the PageMaker file format, subroutine libraries, or memory data structures to develop a plug-in. Because commands and queries are sent directly to PageMaker's existing action and information routines, PageMaker, not the plug-in, is responsible for the integrity of publications. In this way, you can focus your efforts on developing and testing your plug-in, not on preventing negative side effects your plug-in might have on a PageMaker publication.

PageMaker-based syntax

The command and query language is straightforward and simple, based on the actual menu commands or mouse actions (open, paste, getfont, for example). The parameters and coordinates that accompany a command or query mimic the way a user works on a publication. The component interfaces do not follow the user interface like the commands and queries, but each class represents a portion of the PageMaker functionality, and with a little familiarity with the application you should be able to easily determine which interfaces provide the functionality that you need.

PC or Mac: The language is the same

With few exceptions, the PageMaker API is identical in the Windows and Macintosh environments, simplifying the development of plug-ins aimed for both platforms.

Commands

Invoke PageMaker menu commands and perform most user actions (for example, drawing, moving, or resizing objects; setting guides; and inserting text).

Queries

Access information in PageMaker publications (for example, details about individual elements and their placement, the number of pages, the page size, the fonts used, and so on).

Component Interfaces

Provide a more complete access to the PageMaker internal functionality, including the ability to add a floating palette or change a dialog box. Many of the interfaces overlap with the commands and queries, and in these cases the component interfaces are a faster access to those areas of the code, while the commands and queries make the same functionality available to the IAC channel (which cannot use component interfaces.)

Parameters

Many menu commands access dialog boxes, which solicit additional information from the user. Where appropriate, plug-ins commands require you to include this information in parameters and thereby bypass the dialog box. For example, to open the file income.p65, the command is open "income.p65" from an application using IAC, or POpen("income.p65) using the command and query classes.

To avoid long parameter lists for dialog boxes that contain numerous entries and choices, certain commands have been broken into several commands. For example, four script-language commands cover the File > Document Setup menu command: PageMargins, PageNumbers, PageOptions, and PageSize.

Types of plug-ins

Plug-ins fall into two categories:

You write plug-ins in C++, and compile and link the source files into a Windows DLL, or a Power Macintosh shared library.

With few exceptions, the command and query language is identical in PageMaker for Windows and for the Macintosh. Therefore, you can develop a plug-in that can be marketed in both environments. By avoiding environment-specific language and compiler features and by conditionally isolating platform-dependent code, your plug-in source code can have a fair degree of portability.

Types of Loadable Plug-ins

PageMaker allows plug-ins to be listed on the Plug-ins submenu, found in the Utilities menu. However, you may choose not to list your plug-in in the menu if you create a palette, (which you would add to the Plug-in Palettes submenu under Windows) or if you create a plug-in that is launched by a PageMaker event, like one that replaces a PageMaker dialog box. The type of plug-in you create will typically determine where and how your plug-in is invoked.


Comments or suggestions? Contact Adobe Developer Support
Copyright © 1997 - 2001 Adobe Systems Incorporated. All rights reserved.
Legal notices and trademark attributions