|
Harlequin RIP SDK
|
|
|
|
Harlequin RIP SDK
|
|
A full-featured RIP integration. More...
Modules | |
| Main entry point and command-line parsing | |
| Raster output backends | |
Files | |
| file | generateformat.c |
| Filename generation from a format for "clrip" application output files. | |
| file | generateformat.h |
| GenerateFormat function. | |
| file | ldkapi.h |
| Functions for LDK security. | |
| file | namedcolorlookup.c |
| Example of a PostScript device type to implement named color lookup. This example is unusual in that it is split into two files. | |
| file | photoinksplitter.c |
| Example of a PostScript device type to implement photoink splitting. This example is unusual in that it is split into two files. The photoinksplitter.c file (this file) contains the device specific code for light/dark splitting algorithms. It should be rewritten for each device. The photoinkdev.c file is in skinkit. It contains boilerplate code for a PostScript device that acts as the intermediary between the RIP and the photoink splitting algorithms. This file is not expected to require any changes. | |
| file | skintest.c |
| Core implementation of the interaction between the RIP and the skin. | |
| file | skintest.h |
| This file declares various utility functions used to form the example command-line RIP application. | |
| file | skintestdata.c |
| Global data used by skintest. | |
| file | skintestdata.h |
| Global data used by skintest. | |
Macros | |
| #define | SCALABLERIP |
| #define | OUTPUT_TARGET_FILE "FILE" |
| Name used for file output target. | |
| #define | OUTPUT_TARGET_NONE "None" |
| Name used for data sink output target. | |
| #define | OUTPUT_TARGET_STREAM "STREAM" |
| Name used for RAW output target. | |
| #define | OUTPUT_TARGET_SOCKET "SOCKET" |
| Name used for socket output target. | |
| #define | OUTPUT_TARGET_PRINTER "PRINTER" |
| Name used for printer output target. | |
Enumerations | |
| enum | MONITOR_FILE_OPTIONS { MONITOR_FILE_NOSTDOUT = 1 , MONITOR_FILE_STDERR = 2 , MONITOR_FILE_NOLOG = 4 , MONITOR_FILE_FLUSH = 8 , MONITOR_FILE_FLUSHNL = 16 } |
Functions | |
| void | ListSetupsAndConfigs (SwLeDoParams *params) |
| This function runs RIP to list available output types and configuration names. More... | |
| int32 | ProcessJobs (SwLeDoParams *params) |
| Boot the Harlequin RIP core and process jobs from input queues. More... | |
| void | FileFormat (uint8 *format) |
| This function allows you to override the default output format. Supported output format names can be found in skintest.c. More... | |
| HqBool | GenerateFilename (const char *format, const RasterDescription *pRasterDescription, uint8 *pFilename, int32 length) |
| Generates a filename or message for this job / page / sep. More... | |
| HqBool | GeneratePSFilename (const char *fileformat, const RasterDescription *pRasterDescription, uint8 *pFilename) |
| Generates a PS filename for this job / page / sep. More... | |
| void | OverridePGBType (uint8 *type) |
Called in response to the example command-line application's -o (output) switch, this function is used to override any value of /PageBufferType from the page device. If the existing value is "LE", then the override will be performed silently; for other values, a warning will be issued. | |
| uint8 * | GetPageBufferType (int32 *pLen) |
| Obtain the PageBufferType in use, taking into account any override value. More... | |
| void | OverrideOutputTarget (uint8 *target) |
Called in response to the example command-line application's -s (output target) switch, this function is used to override any value of /OutputTarget from the page device. | |
| HqBool | PTNextDrive (int32 index, uint8 *pDrivename) |
| Called by MountAllDrives() to get the next (first if index == 0) drive that is on the machine. More... | |
| HqBool | RasterFilename (RasterDescription *pRasterDescription, const char *fileformat, const char *const valid_targets[], uint8 *rasterFilename, uint8 *rasterPSFilename) |
| Raster filename function, used to generate filenames for raster backends from a template and raster description. More... | |
| RASTER_PLANE * | RasterPlaneFromDescription (const RasterDescription *pRD, uint32 pindex) |
| void | PrintCopyright (void) |
| Output the content of COPYRIGHT.txt to the monitor. | |
| HqBool | monitorFileStart (SwLeMONITORCALLBACK *monitorCallback) |
| Initialise the monitorFile() output. More... | |
| void | monitorFileEnd (void) |
| void | monitorFile (uint32 buflen, const uint8 *buffer) |
| intptr_t | monitorFileOptions (intptr_t options) |
| HqBool | monitorFileHandleEvents (HqBool monitorCompatible) |
| Register event handlers to contextualise monitor events, sending them to an appropriate monitor file stream. More... | |
| void | jsonSavePS (void) |
| Enable saving of PostScript representation of JSON config files. | |
| void * | CurrentJobContext (void) |
| Return the job context attached to the currently processing job. This is the job context pointer provided to raster callbacks, initially created by the input queue job submission. | |
| void | HqCustomAssertMon (const char *pszFilename, int nLine, const char *pszFormat, va_list vlist, int assertflag) |
| Wrapper for HqCustomAssert() to ensure output goes to the stderr channel, rather than the stdout channel, when using the monitor file callback. | |
| void | HqCustomTraceMon (const char *pszFilename, int nLine, const char *pszFormat, va_list vlist) |
| Wrapper for HqCustomTrace() to ensure output goes to the stderr channel, rather than the stdout channel, when using the monitor file callback. | |
| void | init_C_runtime_skintest (void) |
| Re-initialize all global state in the clrip application layer. More... | |
A full-featured RIP integration.
The clrip application layer is a fully-functional command-line RIP that can accept jobs, configure the RIP (for different resolutions, page sizes, color modes and interleave formats), and can output rasters. The clrip application can accept input from the command line, but can also monitor one or more hot folders. The clrip application supports TIFF and RAW output by default, and may support other output formats depending on your licensing options. Output may be written to files, sent to a TCP/IP socket, or diverted to a data sink for performance testing or pre-flighting applications.
If your licensing agreement with Global Graphics includes the Scalable RIP, the clrip application implements Scalable RIP functionality, allowing it to distribute RIPping across multiple processes.
The clrip application includes example color management and halftone modules that demonstrate how to integrate alternate color management systems or halftoning methods into the Harlequin RIP.
The distribution you receive from Global Graphics has a pre-built clrip executable in it. You can use this to test the RIP and ensure it works on your hardware, but for deeper integrations you will probably want to customize and build it yourself, or integrate the Harlequin RIP SDK into your own application.
The clrip application is command-line driven. You will find it in the bin directory of the distribution. To see a full description of the command-line options available:
> .\bin\clrip -h
$ ./bin/clrip -h
Some of the more important options are mentioned below:
Displays the usage information and the available options. Append a switch for more detailed information about that option. For example:
clrip -h f
Lists all the configurations that the RIP has installed along with the PageBufferType values and memory settings.
Processes the named file (or files) specifying no configuration file. That is, the RIP uses the default configuration state. To run filenames containing spaces, enclosing the filenames within double-quotes. Multiple filenames may be specified. clrip also accepts wildcard characters supported by the operating system. For example, on Windows you can use:
Specifying *.pdf as a file name will process all files in the directory that match this pattern. On Linux and MacOS, wildcard expansion is performed by the command-line shell, so the shell's file naming rules and special characters must be observed.
In general it is recommended that the input file names are the last items specified on the command line, however it is possible to run multiple files with different configurations by interleaving the configuration options with the input filenames. If submitting multiple filenames for processing in one command line, you may also want to use the -C option to process all jobs in the case that one of them encounters an error.
Processes the file(s) using a specified configuration. The configuration is applied by the RIP just before the each job file is interpreted. The configurations installed in the RIP may be listed using the -l command-line option. Configurations may be modified or extended by using Page Features. Job filenames, hot folders and configurations can be interleaved on the command line, allowing different configurations for each job or hot folder. A job filename or hot folder will use the previous configuration specified on the command line, modified by any page features specified after the configuration but before the job or hot folder name. See Configuring the Harlequin RIP for more information about configurations and Page Features.
Add a Page Feature file to the configuration selected. Multiple page features can be added after each configuration. See the -c option.
Monitor a hot folder for input. When using hot folders, you have to explicitly stop the RIP. When using hot folders, you will probably want to use the -C option to continue to process jobs in the case that one of them encounters an error.
If multiple jobs are presented to the RIP and one of those jobs encounters an error, a Job Not Completed message is issued and the remaining jobs on the command line will not run. Use the -C option to ensure that all jobs are processed.
The -f option generates raster output filenames based upon the input jobname, filename, page and separation names and numbers. Literal characters are copied to the filename, formats preceded by % are expanded.
The available formats may be listed by using:
clrip -h f
Note that format values are case-sensitive. Also, note that <, &, and > are reserved characters on the command line, so when entering them you must use a delimiter before each reserved character, or quote the entire -f argument using single or double quotes. For example, in Windows Command Prompt:
-f %^<xy -f %^<^<xy -f %^>xy -f %^>^>xy -f "%>>xy"
When using -f in a Windows batch file, rather than typing directly into a command line, you must use %% rather than single % at the start of each command.
On Linux or MacOS, use:
-f %\<xy -f %\<\<xy -f %\>xy -f %\>\>xy -f "%>>xy"
If the value of the -f argument ends with a / or a \ then it is taken as specifying only the folder name. In this case the output file names are formed by appending the default format string in the relevant raster backend to this folder name.
For this case only, any %f (input filename) in the format string is interpreted as %b (input base name), i.e., any input folder name is removed. The output folder is created if it does not exist.
On Windows, either \ or / in the folder name for the -f option may be used interchangeably. If the directory name is surrounded by quotes the / or \ at the end must be outside the closing quote.
On Windows, specify the drive types automatically mounted. The default when -D is not used, is to mount CD-ROM, fixed and remote drives. However, you may find that not mounting remote, or CD-ROM drive types improves performance by preventing unnecessary drive checks or network searches.
If your hardware and RIP license supports multiple threads the -p option can be used to specify the number of threads to allow each RIP to use.
The -m option value is specified in mebibytes and is used on the command line to set the default value for the RIP's maximum memory allowance. This option specifies using virtual memory from the OS. See Configuring memory for more information.
Specify the maximum address space to reserve for the VM arena. It is not normally necessary to use this option. See Configuring memory for more information.
Set the emergency memory reserve size specified in mebibytes. If a particular job is so large that it cannot all be fitted into memory at once, the RIP starts to paint partial page buffers to disk. To try and avoid this, you can allocate extra temporary memory for the RIP, using this option. This allows the RIP to use additional physical and virtual memory while completing the job.
The default value for -me is 5 mebibytes, and usually there is not much reason for this to be changed except under rare circumstances such as when RIPping large transparencies and not wanting partial painting and paging to occur. It is not normally necessary to use this option. See Configuring memory for more information.
This option is specified in mebibytes and is used to set the RIP's maximum memory allowance when using a single preallocated block. The command-line options -m, -ma, and -me are incompatible with the -mc parameter. Global Graphics recommends using -m rather than -mc. See Configuring memory for more information.
The amount in mebibytes to reduce and retry memory requests by if the request is unsatisfied. It is not normally necessary to use this option. See Configuring memory for more information.
The -X option copies all monitor output to a single logfile called LE_LGFLE in the SW folder.
The -o switch can be used to override the value of /PageBufferType in the configuration's page device. To view the available choices see the PageBufferType values listed by:
clrip -l
but exclude the leading slash (/).
This option is for testing and debugging only. Do not use it in production, it may not work correctly with raster backend parameters or with the Scalable RIP.
The -s switch can be used to override the value of /OutputTarget in the page device. To view the available choices see the OutputTarget values listed by:
clrip -l
but exclude the leading slash (/) when specifying these values using -s.
This option is for testing and debugging only. Do not use it in production, it may not work correctly with the Scalable RIP.
Use the specified LDK protection key, which skips the "find the best" search and just attempts to use the specified key. If no license is available from that key, e.g., it is already in use, then Harlequin Core will fail to start.
-k and -kp command-line options is also available via the API call secDevSpecifyKeyID(). Use the same LDK protection key as for the previous run of this Harlequin Core instance. Information about which LDK protection key was used is saved in the SW folder, and the same protection key will be used if possible. If no saved information is available the normal search is performed.
-k and -kp command-line options is also available via the API call secDevSpecifyKeyID(). The option adds colorization filters to the mechanism by which textual messages are sent, filtered, localized, logged and output. The optional number selects the mode:
-! 1, but instead of passing the messages through legacy devices, handles the event directly to change color and displays the text. This mode produces slightly more output than the legacy route, because it doesn't feature the same message suppression that the legacy code does. It also features "native" UTF-8 support. If output is redirected to a file you get UTF-8 throughout.-! 1 (that is, via the legacy devices) it also displays the metadata associated with each message, and the timeline type/title as that changes. This allows you to see the metadata which could be used for filtering, logging, error detecting, warning detection and so on, including the unique error code. Unique error codes can be looked up in doc/monitoruids.csv, doc/monitoruids.html, or here. The clrip application has two built-in methods to submit jobs for processing. It can accept jobs from the command line, and it can accept jobs from hot folders. You can use both methods, in which case jobs submitted on the command line will be queued first, and then any jobs from hot folders will be queued. Configurations and page features can be interleaved with jobs and hot folders on the command line, allowing each job or hot folder to have a different configuration if desired.
If you only specify jobs on the command-line, the RIP will quit after processing those jobs. If you specify one or more hot folders for input, the RIP will wait for more input from the hot folders. You can stop the RIP by dropping a special PostScript job into a hot folder. It is also possible to use the special PostScript in a configuration for a hot folder, so putting any file (including a zero-length file) in that hot folder will stop the RIP.
Jobs copied into hot folders will be deleted from the hot folder after processing, even if processing encountered an error. Note that the output must be redirected to a different location (using the -f command-line option) when using hot folders. clrip's default output location is to put rasterized page files beside the input file. When reading from a hot folder, this would write the output files back into the hot folder, and clrip would then see them as new files to be processed, resulting in an endless loop. An error will be issued and the RIP will quit if a hot folder is used without changing the output location or output target. clrip does not check whether the new output target or output location is safe, nor whether it is even required for the configuration. This error is intended to catch the most likely inadvertent problem with configuring hot folders, not to prevent against malicious configuration.
It is highly recommended that the -C option is used when running with hot folders or submitting multiple jobs to the RIP, to prevent jobs with errors in them from causing the RIP to quit. A warning will be issued if this option is not used when hot folders are configured.
If your licensing agreement with Global Graphics includes the Scalable RIP, the clrip application implements Scalable RIP functionality, allowing it to distribute RIPping across multiple processes.
clrip may be started as a Scalable RIP by specifying the -nrips command-line option to specify the number of Farm RIPs to use and the -m command-line option to set the amount of memory available.
When the HHR is run in Scalable RIP mode, it will initially act as the controlling RIP. This will spawn a number of HHR clone processes, referred to as Farm RIPs. The Farm RIPs will be spawned transparently, with customer code not needing to know whether the HHR is running in Scalable RIP mode or not. The most visible difference is increased performance because jobs will be efficiently processed using all the Farm RIPs.
When running clrip as a Scalable RIP:
When used as a Scalable RIP, there are some additions and modifications to command line options:
If Scalable RIP functionality is enabled, launch the RIP as a Scalable RIP with the number of Farm RIPs specified.
The -m option must be specified when running as a Scalable RIP. The amount of memory specified is divided by the number of Farm RIPs to set the amount available for each RIP. The -m option may be used twice when using Scalable RIP. If -m is used a second time and appears after the -nrips command-line option, it sets the amount of memory to use for the controller RIP. The controller RIP is normally given a minimal memory allocation, just enough to be able to parse jobs and extract metadata from them. If there are large color profiles or other configuration items that take a lot of memory, or exceptionally large jobs are processed in the workflow, it may be necessary to give the controller RIP more memory.
Override the default Scalable RIP configuration directory. See Configuring the Scalable RIP. If the Scalable RIP is launched using the RIP Farm API and library then this option will have no effect and the configuration loaded by the integration DLL will be passed to the Scalable RIP.
Register the Scalable RIP message interface as a persistent input source. This allows Scalable RIP integrations using the RIP Farm API and library with a DFE to keep running while waiting for job submission from the library, without having to use a hot folder to keep the RIP running. You should add this option to the command line specified in the SpawnBeforeFarmStart JSON configuration object when using the RIP Farm API.
The -o command-line option is not supported by Scalable RIP. It will not override /PageBufferType in the pagedevice; set this in your configuration instead.
The -s command-line option is not supported by Scalable RIP. It will not override /OutputTarget in the pagedevice; set this in your configuration instead.
The Scalable RIP uses the union device to combine a writable file system device with the readable SW data directory. Each Farm RIP will write its log file into a separate directory, named SWfr-001 for the first Farm RIP, increasing numbers for the other Farm RIPs. The individual Farm RIP logs in SWfr-001/LE_LGFLE etc., will only contain log data for the page ranges scheduled on that RIP.
The Scalable RIP will write the file blade_guid.json into the working directory on startup. This file is used to keep the machine (blade) identifier for a Scalable RIP controller or satellite blade controller the same across runs. You may be delete this file if you wish, but the blade identifier will change on the next run. This probably only matters if you are using the blade identifier to keep persistent logs or to identify the location of raster data files.
On Windows, there are two methods of building the RIP:
To re-build clrip using the Windows command-line, open a command prompt, and set up the build environment variables:
> C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat amd64
The exact path may differ in the version of Visual C you have installed, but there should be a vcvarsall.bat batch file somewhere in the installed programs. If you start the command prompt using one of the shortcuts installed by Visual Studio, then running this batch file will have already been performed for you.
Find the directory in which you unpacked the Harlequin RIP distribution, change to the bin sub-directory, and run the nmake command:
> cd C:\Users\me\HHR_SDK_14_0\bin > nmake
Note that this will overwrite the pre-built executable supplied in the distribution.
The Makefile can be edited to enable or disable some features of the RIP. In general, you should just edit the variables named USE_FEATURE=value to set the value to 0 to disable or 1 enable a feature.
To build the RIP using the Visual Studio solution, find the directory in which you unpacked the distribution, and open the hhr.sln solution file.
You may need to retarget the solution to the tools installed for your version of Visual Studio. You can do this from the Project menu, or by right-clicking the root of Solution 'hhr' in the Solution Explorer window. You can then build clrip from the Build menu, or using the Ctrl-Shift-B keyboard shortcut.
Some of the clrip features can be enabled or disabled by editing the Visual Studio properties file vc/hhroptions.props. This can be done using the properties editor by selecting View->Other Windows->Property Manager from the menus, expanding the appropriate build configuration from the "clrip" project section, and double-clicking "hhroptions". The "User Macros" section of the properties page contains the properties and their values. Set the value to 1 to enable the feature named, 0 to disable the feature.
You should build the clrip application using the Debug or Release configurations. Customers should not build RIP applications with the SDK library linked as a dynamic library without Global Graphics' approval.
The Visual Studio solution comes pre-configured to run an informational test file provided in the RIP's SW data directory. If the tools do not need retargetting, you should be able to open hhr.sln and press the F5 function key, and the solution will automatically rebuild clrip, run the test file, and produce a TIFF output file named HQNCoreWelcomePage-1.TIFF in the distribution directory.
On Linux and MacOS, the compiler toolchain should be on your PATH already. To re-build clrip, open a terminal, find the directory in which you unpacked the Harlequin RIP distribution, change to the bin sub-directory, and run the make command:
$ cd ~/HHR_SDK_14_0/bin $ make
Note that this will overwrite the pre-built executable supplied in the distribution.
The Makefile can be edited to enable or disable some features of the RIP. In general, you should just edit the variables named USE_FEATURE=value to set the value to 0 to disable or 1 enable a feature.
The clrip application contains a number of raster backend implementations, illustrating capabilities and features of the Harlequin RIP and SDK. To see the raster backends available, look at the PageBufferType values listed by:
clrip -l
The raster backends are documented in Raster output backends.
The clrip application contains built-in examples modules that implement the alternate color management API. Some of the the built-in CMM examples may be useful as-is.
The clrip application contains built-in example modules that implement the halftone screening API. The quality of the example halftone screening modules is not sufficient for production. They should be treated as tutorials in integrating modular screening only.
The clrip application may be used as a model for implementing your own Harlequin RIP integration. It is not the simplest integration, but it does solve a number of real-world problems that you will also need to solve when integrating the Harlequin RIP. The clrip application broadly follows these phases:
| #define SCALABLERIP |
Undef this to remove Scalable RIP options.
| enum MONITOR_FILE_OPTIONS |
Option bits determining where the monitorFile() function sends its output. A combination of these bits can be passed monitorFileOptions() to modify how monitor output is handled. These options have to be organised such that the default setting is zero, because threads that have not explicitly set the options will get this value.
| void FileFormat | ( | uint8 * | format | ) |
This function allows you to override the default output format. Supported output format names can be found in skintest.c.
format strings that are passed to it.| format | A NUL-terminated string, which should be a supported output format name. |
| HqBool GenerateFilename | ( | const char * | format, |
| const RasterDescription * | pRasterDescription, | ||
| uint8 * | pFilename, | ||
| int32 | length | ||
| ) |
Generates a filename or message for this job / page / sep.
| format | A NUL-terminated format string, containing percent-escaped format characters supported by GenerateFormat(). |
| pRasterDescription | The raster description for this job / page / sep. |
| pFilename | A buffer to hold the generated filename. |
| length | The length of the pFilename buffer. |
TRUE if pFilename was filled in successfully; FALSE otherwise.Neither the input format nor output pFilename are required to represent filenames. This function expands format specifiers using information present in pRasterDescription. The output may be used as a filename, or as a message, or any other use the caller desires.
| HqBool GeneratePSFilename | ( | const char * | fileformat, |
| const RasterDescription * | pRasterDescription, | ||
| uint8 * | pFilename | ||
| ) |
Generates a PS filename for this job / page / sep.
| fileformat | A NUL-terminated format string, containing percent-escaped format characters supported by GenerateFormat(). |
| pRasterDescription | The raster description for this job / page / sep. |
| pFilename | A buffer of at least LONGESTFILENAME length to hold the generated filename. |
TRUE if pFilename was filled in successfully; FALSE otherwise. Obtain the PageBufferType in use, taking into account any override value.
| pLen | Set to the length of the returned string. |
| void init_C_runtime_skintest | ( | void | ) |
Re-initialize all global state in the clrip application layer.
It is only necessary to call this function when booting the RIP multiple times within the lifetime of the host process. If you are only going to boot the RIP once, then it is unnecessary (although quite harmless) to call this function.
When used, this function should be called as the very first action in the overall bootup cycle. This is because the function resets all state, so it will undo any initialization work performed by other startup calls. A useful way to think of this function is that it is similar to the effect of terminating and re-starting the host process.
| void ListSetupsAndConfigs | ( | SwLeDoParams * | params | ) |
This function runs RIP to list available output types and configuration names.
| [in] | params | The memory and monitor configurations required to run the RIP to retrieve configuration names. |
Send a buffer of output to the chosen output file stream, and also any log files mentioned on the command line.
| buflen | The length of the message to output. | |
| [in] | buffer | A buffer of data to output. This is written to stderr verbatim. |
| void monitorFileEnd | ( | void | ) |
Finalise the monitorFile() output.
This function destroys the thread-local contextualisation of monitor output, and re-installs a default monitor handler that outputs to standard error only.
Register event handlers to contextualise monitor events, sending them to an appropriate monitor file stream.
| monitorCompatible | Compatibility flag for pre-Harlequin 12 SDK behaviour. If this is TRUE, then messages sent to the MON_CHANNEL_STDERR event channel from the RIP are sent to stdout rather than stderr. |
| TRUE | The event handler(s) were installed successfully. |
| FALSE | The event handler(s) could not be installed. |
This function is separate from monitorFileStart() because it must be called after SwLeSDKStart().
| intptr_t monitorFileOptions | ( | intptr_t | options | ) |
Set the output file and options that monitorFile() will use for this thread.
| [in] | options | A combination of the MONITOR_FILE_OPTIONS enumeration values. |
| HqBool monitorFileStart | ( | SwLeMONITORCALLBACK * | monitorCallback | ) |
Initialise the monitorFile() output.
The monitorFile() output routes monitor information callbacks to the process's standard output, standard error, and configured log files. On initialisation, the skin sets a monitor callback that outputs to standard error only.
| monitorCallback | A function used to prepare monitor output for sending to file. This function should call monitorFile() with the prepared buffer. If no preparation is required, monitorFile() may be supplied as the parameter. |
| TRUE | if the monitor file output was initialized successfully. In this case, the LE SDK default monitor callback has been set to the monitorCallback parameter. The monitorFileOptions() function may be called for each thread independently to modify how they send output to the monitor information files. |
| FALSE | if the monitor file output was not successfully. Neither monitorFile() nor monitorFileOptions() should be called. |
| int32 ProcessJobs | ( | SwLeDoParams * | params | ) |
Boot the Harlequin RIP core and process jobs from input queues.
| [in,out] | params | Parameters for SwLeDo(), preset with the memory sizes determined during SDK start. |
Called by MountAllDrives() to get the next (first if index == 0) drive that is on the machine.
FALSE when there are no more drives, and TRUE if it has more. The returned pDrivename can be an empty string. | HqBool RasterFilename | ( | RasterDescription * | pRasterDescription, |
| const char * | fileformat, | ||
| const char *const | valid_targets[], | ||
| uint8 * | rasterFilename, | ||
| uint8 * | rasterPSFilename | ||
| ) |
Raster filename function, used to generate filenames for raster backends from a template and raster description.
| [in] | pRasterDescription | The current raster description. |
| [in] | fileformat | The format string for the output file name. The format string may contain the percent-escaped format characters supported by GenerateFormat(). |
| [in] | valid_targets | The valid output targets for the backend. |
| [out] | rasterFilename | A location to store the platform-encoded filename, with at least LONGESTFILENAME bytes of space available. If this is NULL, then the platform-encoded filename will not be saved. |
| [out] | rasterPSFilename | A location to store the PostScript-encoded filename, including the device name, with at least LONGESTFILENAME bytes of space available. If this is NULL, then the PostScript-encoded filename will not be saved. |
| TRUE | The filename(s) were generated successfully. If the output target was set to NONE, then the PostScript filename encodes a discard stream on the stream device. |
| FALSE | The filenames were not generated successfully. |
| RASTER_PLANE* RasterPlaneFromDescription | ( | const RasterDescription * | pRD, |
| uint32 | pindex | ||
| ) |
Get the raster plane current being rendered in an (unpacked) raster description.
| [in] | pRD | A raster description. |
| [in] | pindex | The raster plane index, counting across all planes of all frames in the separation, after separation omission. This is the measure used by the (final) plane parameter to the RASTER_WRITE_DATA_EX callback function. |
This function does not take a reference on the raster description's raster layout. It is the caller's responsibility to ensure that it remains valid while the raster plane pointer returned is being accessed.