(v13) The functions and callback functions
This page applies to Harlequin v13.1r0 and later; and to Harlequin Core but not Harlequin MultiRIP.
The functions and callback functions can be found in the .c and .h files within \skinkit\export\
and \skinkit\src\
folders.
This should be used when restarting the RIP. It initializes skinkit variables prior to starting the RIP. | |
This prepares the memory arena that the RIP uses, and initializes some support libraries. | |
A call to this function is optional, and if called, it must be before the first call to | |
This is optional and initializes memory for the Harlequin Core, giving it a memory buffer of a given size to work in. | |
Sets the callback functions that the RIP calls back to the skin. | |
Sets a callback function to determine what to do with blank pages omitted, trimmed, or detected by the RIP. | |
Adds | |
This starts the RIP. | |
| |
This prepares the RIP to accept the job. | |
This passes a buffer of PostScript language or PDF to the RIP. Global Graphics recommends using | |
This tells the RIP that the current job has no more data. | |
This function should only be called in between job boundaries. It submits a shutdown PostScript language job to the RIP, then waits for the RIP to exit. | |
This should be called before | |
Performs shutdown operations when the application exits. |
These functions are detailed below, also see the file skinkit.h in the \skinkit\export\
folder.
All memory handling in skinkit should use the routines provided by mem.h, (that is, MemAlloc()
and MemFree()
). There are two separate groups of allocators: MemAlloc()
means allocate memory within the skin's pool of RIP memory, and SysAlloc()
means allocate the memory via the operating system, unless overriding functions are provided.
The MemRealloc()
function is provided to assist in the integration of third-party libraries such as Expat, allowing their memory management to be wired up to the skin pool.
The job submission interface is primarily made up of the functions SwLeStart()
, SwLeProcessInputQueue()
and SwLeStop()
. When these functions are used the RIP is started up on a separate thread.
A typical host application, which is reading or manufacturing a PostScript language stream, has the following structure (described here in pseudo code):
SwLeInitRuntime(...)
for ( <all different RIP instantiations or configurations> ) { SwLeSDKStart()
<any time after SwLeSDKStart, start adding jobs to the input queue with inputq_print_job()...>
SwLeSetRipRendererThreads(...)
<optionally initialise RIP memory, required if registering modules later> SwLeMemInit(...)
SwLeSetRasterCallbacks(...) SwLePgbSetCallback(...) SwLeAddCustomDevices(...)
<optionally register core modules and interfaces> SwRegisterCMM(...)
SwRegisterHTM(...) SwRegisterRDR(...) SwRegisterPFIN(...)
SwLeStart (...)
do {
switch ( SwLeProcessInputQueue() ) { case <no more jobs> do <terminate loop>
case <error in job> do <abnormal job action>
}
<post-job actions>
} while <not done> SwLeStop()
SwLeSDKEnd()
}
SwLeShutdown()