(v13) Why the plugin interface was developed
This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core
The main goals of the plugin interface are to permit device independence, OEM development, modular code, and to provide a decoupled interface, consistent error reporting and recovery, mix‐and‐ match configuration, and allow easier maintenance.
Device independence
Within the limits stated here, all versions of the RIP using plugins can drive existing and future devices without special changes to the user interface or to other plugins.
A plugin, when developed correctly with any given version of the plugin kit, should always work with future versions of the RIP, although enhancements made after the plugin was written will not always be available. However, it should be noted that Early Screening Modules developed for v7.x RIPs cannot be used in v8.0 and later RIPs without being rewritten as Core Screening Modules.
Some plugins will also work with versions of the RIP older than the plugin kit with which they were developed. Either the plugins do not require those new features to have been added or they are aware of the differences and adapt appropriately (to work with a smaller set of features).
OEM development
Because Global Graphics has published the plugin interface, you can design, implement and maintain your own device driver software for interfacing to proprietary hardware or protocols. You can also design, implement and maintain your own data filters and other input services. You do not need access to the RIP source code to add a new input or output device to your own RIP setup.
Modular code
The plugin interface defines the interface between the RIP and the various input and output devices very clearly. Device support is separate from the main RIP product: the basic RIP product supplied by Global Graphics does not have to provide direct support for all known devices.
As a result, the RIP is as compact as possible and very reliable. Maintaining and improving the RIP would be an impossible task if it were required to support every known device directly. Worse, under such a scheme a new release of the RIP would have to be made whenever the specifications of a particular device changed.
Global Graphics' own changes and extensions to the plugin interface are done carefully within the RIP, meaning in general that existing plugins continue to work without the need for modification. Another benefit of modularity is that OEMs who need to change their plugins can do so freely, without any need to consult Global Graphics.
Consistent error reporting and recovery
When error conditions occur, they can be handled appropriately by reporting them to the RIP using error codes and types from a standard set. The plugin is only responsible for reporting error conditions, not for deciding how to deal with them - though the kind of error it states has occurred obviously influences the RIP's response.
Mix-and-match configuration
Plugins are created as individual files, so you and your end‐users can configure systems to drive a particular device or range of devices with a minimum of effort.