(v13) Halftone select

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

This makes a Screening module aware of a request from the PDL for the potential use of a single Halftone, enabling the screening module to verify the request and accept or reject it.

The request might originate from a PostScript language sethalftone operator, or from appropriate changes to the graphics state, such as save/restore.

All such requests appear to the screening module as though they were defined using a halftone dictionary, even though the request may have originated in some other form within the PDL.

(The /HalftoneType value for these halftone dictionaries is100.)

The association of the request with an individual screening module is provided by a mandatory /HalftoneModule key within the halftone dictionary.

The contents of this halftone dictionary are made available to the screening module as part of the details associated with the halftone select together with some information describing the target destination Raster.

The screening module's response to a halftone select is an opaque value, representing an instance of that halftone, and is used by the RIP to refer to uses of that halftone.

The screening module must maintain the validity of that instance value until notified by the RIP via a halftone release.

Where possible, the screening module should return the same instance value for a subsequent halftone select sharing the same properties, that is, several separate requests from the PDL for what is fundamentally one and the same halftone should all return the same instance value.

If the screening module deems the halftone select invalid it should, wherever possible, identify a key within the halftone dictionary as probable cause of complaint.

The RIP does not attempt to cache or bypass halftone selects, nor the resulting instance values, but reserves the right to do so in the future.

Note that it is possible for the RIP to invoke a halftone select and subsequently release the instance without having used the halftone for any objects. A halftone select does not imply that the halftone will necessarily be used for rendering.

Note also that many changes to the graphics state may take place when preparing a job, and that the RIP itself may therefore invoke HalftoneSelect many times, seemingly repeating itself. What the RIP is actually doing is calling the screening module to ascertain whether different halftone instances are needed under the new circumstances. If they are different, the RIP will usually then release the earlier ones. If the module returns the same halftone instance, on the other hand, the RIP will release the duplicates and continue.

Colorant-specific halftones

The halftone select operation establishes an instance value for a single colorant.

The RIP performs a separate and distinct halftone select operation for each potential colorant.

Even without a module making different choices for colorants, a type 5 dictionary (in the job or the configuration) can specify wholly different screening mechanisms or modules for different channels of the same pixel. Situations wherein some channels within a pixel utilize different halftoning from others may also arise as a result of overprints.

When all the screening mechanisms involved are capable of processing each channel individually, pixels made up of several different screening mechanisms should pose no particular problem.

Some screening mechanisms, however, exploit the interrelationships between color components and therefore need to have all color values (for channels relevant to them) available as and when they process each pixel. Nevertheless, the use of spot colors might mean there exist, within a pixel, color channels not relevant to such interrelationships; such channels can reasonably be expected to demand the use of a different screening mechanism or halftone.

The dilemma is that there may be pixels, within the raster, some of whose channels are interrelated and should be considered as a whole by one screening module, whilst other channels should be processed individually by another screening module or modules.

To resolve this, the RIP requires screening modules needing interrelated channels to do two things:

Declare those color channels they deem interrelated. This is notified to the RIP using the underlying properties of the halftone instance value.
Return the same halftone instance value from a halftone select for all of those interrelated channels.

These together ensure that, from the RIP’s point of view, all the interrelated channels can be halftoned using a single call of DoHalftone.

NOTE: Interrelated channels cannot be used in conjunction with frame interleave.

NOTE: The interrelated channels feature is not implemented yet.

Raster description in the screening API

The halftone select operation gets a description of the output raster as an argument. This includes an array describing the device colorants and the output channels in the raster. While the elements are called sw_htm_colorant_info , the array is really organized by channel.

NOTE: If the module inspects the raster description and it is intended to work with configurations unknown to the module writer, careful attention is required to correctly interpret this description. In some configurations, some colorants may appear on multiple channels, or unused channels may not have a valid colorant, and the set of channels may change during the page.

Colorants may appear on multiple channels due to separation detection in a preseparated job, or simply because the configuration defines multiple channels with the same colorant.
Unused channels may occur due to separation omission, or simply because the configuration doesn't use all fixed channels on some separations.
The set of channels may change due to automatic spot color addition or separation omission.

For details of separation configuration see Configuring the page device in the Harlequin Extensions Manual .