[Gs-devel] FW: New Device routines for DeviceN Color Implementation

[Dan Coby]

Raph asked me to produce a short document on the routines that
I am adding to the device structure for the implementation of
DeviceN color handling.

This list is subject to change (and does on a regular basis).
This list is know to not be complete.  I am adding things as I
need them during the implementation.  Jan Stoeckenius has
suggested several additions that I currently have not implemented.


The first routine to be added is a routine that returns information
about the process color model(s) supported by the device.
Currently this routine returns a pointer to a structure which
contains information about the device's current process color
model.  In the device structure's procs field this routine could
be accessed via dev_proc(dev, get_process_color_model)(dev).
However it is normally accessed via a macro defined as:

#define gx_get_process_color_model_info(dev) \
    (dev_proc(dev, get_process_color_model) ? \
        dev_proc(dev, get_process_color_model)(dev) : \
    	gx_default_get_process_color_model(dev) \
    )

The macro is used to check if the device supports this routine.
If not then a default routine (gx_default_get_process_color_model)
is called instead.  None of the current drivers have this routine
defined within their device definitions.  The default routine
checks the number of components (1, 3, or 4) and assumes either
DeviceGray, DeviceRGB, or DeviceCMYK for a process color model.

For a device which will support a DeviceN process color model or
even one of the standard color models with spot colors, this
routine needs to be defined.

The routine returns a pointer to a structure.  The structure
currently contains three pieces of information:
1.  Enum - The process color model
2.  Boolean - spot colors supported
3.  Boolean - Additive or subtractive inks.
This information was being derived inside the graphics library
based upon the number of components in the device.  (The current
Adobe documentation describes the color components of the device's
process color model as 'colorants'.)


Two macros and a routine return the individual fields:
/*
 * This will return the device's process color model.
 */
#define gx_get_process_color_model(dev) \
    ((gx_get_process_color_model_info(dev))->process_color_model)

/*
 * This will return the device's spot color support flag
 */
bool get_spot_color_support(P1(gx_device *));

/*
 * This will return the device's if the process color models inks are
additive.
 */
#define get_additive_inks(dev) \
    ((gx_get_process_color_model_info(dev))->additive_inks)


For those devices that use one of the standard process color models,
a set of routines (one for each of the standard process color
models) has been created.


Every DeviceN device must also define the following color mapping
routines.  These map a DeviceN color to a gx_color_index (and back).


/*
 Map a DeviceN color to a color value
*/
#define dev_t_proc_map_devicen_color(proc, dev_t)\
  gx_color_index proc(P3(dev_t *dev,\
    gx_color_value *pcolor, gs_devicen_color_map *pcomp_map))
#define dev_proc_map_devicen_color(proc)\
  dev_t_proc_map_devicen_color(proc, gx_device)

/*
  Map a color value to a DeviceN color
*/
#define dev_t_proc_map_color_devicen(proc, dev_t)\
  int proc(P4(dev_t *dev, gx_color_index color,\
    gs_devicen_color_map *pcomp_map,\
    gx_color_value devicen[GX_DEVICE_COLOR_MAX_COMPONENTS]))
#define dev_proc_map_color_devicen(proc)\
  dev_t_proc_map_color_devicen(proc, gx_device)


The last piece of information that is currently obtained from
the device is a list of the colorants for the device.  This is
known for the standard process color models but needs to be
specified for spot color support and for DeviceN colors.  The
current code has this being pulled directly from the device
structure.  Raph has suggested that a routine be created for
this information.  (I agree.)