Scalable RIP raster delivery order

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

The Raster Manager built into the Scalable RIP provides an API to receive notifications of rasters ready for output, and to request delivery of the metadata for those rasters and indicate processing of those rasters. The Raster Manager does not attempt to manage storage or transmission of raster data, it only handles metadata about the rasters, representing the raster as your specified name, location, data format, and your optional supplied metadata string. The raster manager provides an interface to a collated stream of pages for each job, with raster information for each page, accessed through a single interface.

Use of the Raster Manager API is optional. If the Raster Manager API is not used, the sequencing of rasters being delivered cannot be known. The Scalable RIP works by launching N + 1 (command-line option -nrips N) RIPs. One RIP is the controlling RIP and the specified N farm RIPs do the interpretation and rendering of jobs or page ranges for PDF jobs. Since PDF files are likely to be split amongst multiple farm RIPs, the delivery of rasters for a job are in the order of completion by the farm RIPs. Also, since the Scalable RIP can process multiple jobs simultaneously, it is possible that rasters for a later job be delivered before a job submitted prior to it. For example:

• Example 1 (-nrips 2, chunk size is 1, jobA is an 8-page job) Imagine that page 1 of jobA is very complex and pages 2-8 are very simple. It is possible that the rasters for pages 2-8 get delivered before page 1.
• Example 2 (-nrips 2, chunk size is 1, jobA is an 8-page job, jobB is an 8-page job) Imagine that page 8 of jobA is very complex, pages 1-7 are very simple and the whole of jobB is very simple. It is possible that the rasters for pages 1-7 from jobA get delivered, all of the rasters for jobB then get delivered, followed finally by page 8 of jobA.

Finally, it is possible that a farm RIP fails to render a page in a job after all other pages have been rendered successfully; you cannot know if a job succeeded completely until all the rasters for a job have been delivered. Remember that page 1 could cause a rendering error after the rasters for pages 2 to N have been delivered for a particular job.