(v13) Pluggable font interface

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

The Pluggable Font Interface (PFIN) allows the Harlequin RIP font engine to be augmented or even functionally replaced by additional font modules. Multiple modules can exist concurrently to handle various types of font, to supply font resources in new formats, to work around engine limitations, or to allow the same engine to be configured differently for different fonts.

A PFIN font module is registered via the SwRegisterPFIN() call, which passes a sw_pfin_module_api structure to the RIP. The module will be started once the RIP starts, or immediately if the RIP has already started. All further communication between the RIP and module is through the sw_pfin interface. The RIP exposes various useful functions to the module in sw_pfin_api, sw_data_api and sw_blob_api.

The sw_pfin structure contains pointers to both the module’s and PFIN’s call list blocks. These are individually versioned and also include the extent of the block. Consequently, the API is binary backwards-compatible, and future revisions will extend, rather than replace, this initial functionality.

Before any font calls are made to a module, its init function is called to allow the module to initialize any global state, then start is called to initialize a module instance. This allows it to allocate and initialize its workspace, and define any static fonts that it supplies. These operations are not to be carried out when the module is first registered. Before the RIP shuts down, it calls the module’s stop entry point for each active instance, before calling the finish entry point.

Configuration is delivered to individual module instances through a configure call, which is called whenever the configuration changes. Some parts of a module’s configuration are handled by PFIN itself. (For example, whether rejected fonts are passed to another module), most must be handled by the module. Configuring an unknown instance of a module causes that instance to be created, calling the module’s start entry point first.

Unknown fonts are sought through the find entry point, which allows the module to define fonts on demand, instead of in advance (during start). Individual glyphs are interrogated through the metrics, outline and raster calls. The module must switch between fonts as required. There is also a miscop entry point that allows module-specific interaction via the pfinop PostScript language operator.

PFIN provides memory allocation, file and data handling routines, and the ability to define and undefine fonts and CIDfonts, plus advanced features such as UniqueID and caching control.

PFIN monitors memory allocations and, under low memory situations, may ask a module instance to go into suspension to free as much memory as possible. PFIN will resume the module instance when it is next required. A simple module may just shut down completely, and so will restart when PFIN asks it to resume. A more complex module may free cached data whilst maintaining minimal contextual information, and will recommence caching when resumed.