(v13) Uses for RDR by the RIP core

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP

The main use for RDR by the Harlequin RIP core code is for discovery of externally provided implementation code for APIs. This allows OEMs to share libraries used by a RIP integration to upgrade libraries provided by Global Graphics and to provide custom implementations for some functionality.

The RIP also uses RDR so that optional code, such as the UFST module, can rely on data supplied by the RIP skin without requiring a proprietary skin interface and associated build variance.

This allows the OEM to supply a variable number of UFST font resources, or to omit them entirely, with no other configuration or build changes.

Code can register internal data or tables as a default RDR (of a very low priority such as RDR_PRIORITY_DEFAULT), which other code can then optionally override with its own RDR.

RDRs can be registered or re-prioritized contextually, altering behavior at runtime without requiring new interfaces.

De-coupling consumers from suppliers, making both optional and allowing many-to-many relationships simplifies interfaces, build systems, and provides flexible ways of producing sophisticated behavior.