Rendering and Rendering Control Operators

This clause describes the model for rendering and the facilities for controlling how graphical elements and colors are rendered on an instance of the medium by the Presentation Process. The presentation device is the physical agent by which the output of the Presentation Process is rendered onto the media. Use of most of the operators for controlling rendering requires knowing the characteristics of the presentation device. A document that is intended to be device independent should not use any of the operators described in this clause.

Rendering, in the model of the Presentation Process used in this International Standard, is carried out by the Marking and Finishing Process (see and ). The information that controls rendering is captured during content processing, however. This information is taken from a subset of the Graphics State Variables that contain values that control rendering: CurrentBlackGeneration, CurrentColorRendering, CurrentHalftone, CurrentOverPrint, and CurrentUnderColorRemoval. As each image element is placed on the page image (see ), the values of the above Graphics State Variables are saved and associated with the image element to be used when the page image is rendered onto the an instance of the the media. At that time the rendering control information is used as specified below.

Model for Rendering

Nearly all of the rendering facilities that are under program control have to do with the reproduction of shades of colors. The model for rendering is logically a multiple-step process whose semantics are outlined below. Depending on the current color space and on the characteristics of the presentation device, in particular whether it supports continuous-tone output and the set of device colorants, it is not always necessary to perform every step.

The remainder of this clause discusses the use of color rendering Dictionaries in converting CIE-related colors to device colors; the algorithms for conversion between different device color spaces; and the specification of transfer functions, halftone screens, and halftone functions. The operators which provide programmatic control of these various functions are described in . This clause is intended to describe the model for rendering; it is not intended to specify underlying implementation methods. Conforming implementations must, however, provide operators which adhere to the semantics of the operators described in .

Conversions from CIE Color> to Device Color

Conversion from a CIE color value to a device color value requires two main steps:

The source gamut is specified by a document when it selects a CIE color space by executing SetColorSpace. This specification is device-independent.

The device gamut and the color rendering function are described by a color rendering Dictionary, which is a parameter of the Graphics State. The default color rendering Dictionary and its contents are completely implementation-dependent. The SetColorRendering operator installs a new color rendering Dictionary in the Graphics State; the GetColorRendering operator returns the current color rendering Dictionary. The gamut mapping and color rendering function are applied only to color values presented in a CIE color space. By definition, color values in device color spaces control the device color components directly. 35.2.1 contains many references to the contents of color rendering Dictionaries. See for a description of color rendering Dictionaries.

Transforming CIE Color to Device Color

The key/value pairs in a color rendering Dictionary together define a color rendering function that transforms CIE color values to device color values. The output from the color rendering function is subject to further transformations — device color space conversion, transfer function, and halftone function.

Every color rendering Dictionary must have a ColorRenderingType key/value pair whose value is a Cardinal. The value specifies the architecture of the color rendering function as a whole. The remaining entries in the Dictionary are interpreted according to this value. The only color rendering Dictionaries whose semantics are defined by this International Standard are those whose ColorRenderingType is 1. The default color rendering Dictionary on an implementation may have a ColorRenderingType other than 1.

The type of color rendering function represented by a ColorRenderingType 1 color rendering Dictionary is based on a two-stage, non-linear transformation of the CIE 1931 (XYZ)-space. The target space of this transformation is called the render color space. Values in this space can be treated in one of two ways:

The first method is most appropriate for use with additive, linear color devices, while the second method is required for high fidelity reproduction on devices whose color rendition cannot be described by a simple formula.

Conceptually, conversion of a color value from a CIE color space to a device color space involves the following steps:

  1. Transform the CIE-based color value from its original color space to CIE 1931 (XYZ)-space. This transformation depends on the various parameters of the color space.
  2. Adjust the X, Y, and Z values to account for differences in the WhitePoint and BlackPoint of the source and the device. This transformation attempts to preserve color appearance and visual contrast, according to the values of the MatrixPQR and TransformPQR entries of the color rendering Dictionary. The diffuse white and black points of the source are given as the WhitePoint and BlackPoint parameters of the color space; the diffuse white and black points of the device are given as the WhitePoint and BlackPoint entries of the color rendering Dictionary. If the corresponding entries are equal, this step reduces to the identity transformation.
  3. Transform the color value from CIE 1931 (XYZ)-space into the render color space according to the MatrixLMN, EncodeLMN, MatrixABC, and EncodeABC entries of the color rendering Dictionary, producing three components A, B, and C. These three components are arbitrarily named and should not be confused with the A, B, and C components of the CIEBasedABC color space.
  4. If a RenderTable key is in the color rendering Dictionary, use the A, B, and C components to index into this three-dimensional lookup table, yielding an interpolated value. This value consists of 3 or 4 color components, depending on how the table has been defined. Each of these components is transformed by a procedure into a color component in device color space. If there are 3 components, they specify red, green, and blue values according to the DeviceRGB color space; if there are 4 components, they specify cyan, magenta, yellow, and black values according to the DeviceCMYK color space.

If there is no RenderTable, use the A, B, and C components as the device color value directly. If the device's native color space is DeviceGray, the A component specifies the gray value and the B and C components are ignored. Otherwise, the A, B, and C components specify red, green, and blue values according to the DeviceRGB color space.

Color Rendering Dictionaries

This subclause specifies the entries in a color rendering Dictionary. A high-level description of the use of these entries in the CIE color to device color conversion process is given in .

The mandatory key/value pair <ColorRenderingType: Cardinal> selects the architecture of the color rendering function as a whole. This key/value pair shall be present in all color rendering Dictionaries. The only standard ColorRenderingType provided by this International Standard is type 1. The mandatory and optional entries in a ColorRenderingType 1 color rendering Dictionary (in addition to the mandatory key/value pair ColorRenderingType) are described in .

Color Rendering Type 1 Dictionary

WhitePoint

The mandatory key/value pair <WhitePoint: Vector> is a 3-element Vector of type Number whose elements specify the CIE 1931 (XYZ)-space tristimulus value of the presentation device's diffuse white point. Each element must have a value greater than 0, and the Y component must be equal to 1. The order of elements in the Vector is:

  • [ Xw 1 Zw ]

    BlackPoint

    The optional key/value pair <BlackPoint: Vector> is a 3-element Vector of type Number whose elements specify the CIE 1931 (XYZ)-space tristimulus value of the presentation device's diffuse black point. Each element must have a value greater than or equal to 0, and the order of elements in the Vector is:

  • [ Xb Yb Zb ]

    If the BlackPoint key/value pair is not present, the default value used is:

  • [ 0 0 0 ]

    MatrixPQR

    The optional key/value pair <MatrixPQR: Vector> is a 9-element Vector of type Number whose elements specify the linear interpretation of the encoded X, Y, and Z components of the CIE 1931 (XYZ)-space with respect to the intermediate PQR representation, as described in . The order of the elements in the Vector is:

  • [ PX QX RX PY QY RY PZ QZ RZ ]

    If the MatrixPQR key/value pair is not present, the default matrix used is:

  • [ 1 0 0 0 1 0 0 0 1 ]

    TransformPQR

    The mandatory key/value pair <TransformPQR: Vector> is a 3-element Vector of type Procedure whose elements are Procedures that transform the P, Q, and R components of the intermediate PQR representation to accommodate for differences between the source's and presentation device's diffuse WhitePoint and BlackPoint while preserving color appearance and visual contrast. The order of the elements the Vector is:

  • [ TP TQ TR ]

    Let XWs, YWs, ZWs and XBs, YBs, ZBs be the CIE 1931 (XYZ)-space tristimulus values of the source's diffuse white and black points, respectively. Let XWd, YWd, ZWd and XBd, YBd, ZBd be the CIE 1931 (XYZ)-space tristimulus values of the presentation device's diffuse white and black points, respectively. Then the source and presentation device tristimulus values Xs, Ys, Zs and Xd, Yd, Zd in the CIE 1931 (XYZ)-space , respectively, are related by the MatrixPQR and TransformPQR entries as follows:

    Ps = Xs × PX + Ys × PY + Zs × PZ

    Qs = Xs × QX + Ys × QY + Zs × QZ

    Rs = Xs × RX + Ys × RY + Zs × RZ

    Pd = TP(Ws, Bs, Wd, Bd, Ps)

    Qd = TQ(Ws, Bs, Wd, Bd, Qs)

    Rd = TR(Ws, Bs, Wd, Bd, Rs)

    Xd = Pd × XP + Qd × XQ + Rd × XR

    Yd = Pd × YP + Qd × YQ + Rd × YR

    Zd = Pd × ZP + Qd × ZQ + Rd × ZR

    where

    Ws = [ XWs YWs ZWs PWs QWs RWs ]

    Bs = [ XBs YBs ZBs PBs QBs RBs ]

    Wd = [ XWd YWd ZWd PWd QWd RWd ]

    Bd = [ XBd YBd ZBd PBd QBd RBd ]

    PWs = XWs × PX + YWs × PY + ZWs × PZ

    QWs = XWs × QX + YWs × QY + ZWs × QZ

    RWs = XWs × RX + YWs × RY + ZWs × RZ

    PBs = XBs × PX + YBs × PY + ZBs × PZ

    QBs = XBs × QX + YBs × QY + ZBs × QZ

    RBs = XBs × RX + YBs × RY + ZBs × RZ

    PWd = XWd × PX + YWd × PY + ZWd × PZ

    QWd = XWd × QX + YWd × QY + ZWd × QZ

    RWd = XWd × RX + YWd × RY + ZWd × RZ

    PBd = XBd × PX + YBd × PY + ZBd × PZ

    QBd = XBd × QX + YBd × QY + ZBd × QZ

    RBd = XBd × RX + YBd × RY + ZBd × RZ

    XP XQ XR YP YQ YR ZP ZQ ZR = PX PY PZ QX QY QZ RX RY RZ - 1

    In other words, the Xs, Ys, and Zs components of the source color in CIE 1931 (XYZ)-space are treated as a three-element Vector and multiplied by MatrixPQR (a three by three matrix), yielding the Ps, Qs, and Rs components of the source color with respect to the intermediate PQR representation. These components are individually transformed by the TransformPQR Procedures, producing the Pd, Qd, and Rd components of the corresponding device color. Each of the components is transformed separately; there is no interaction between the components. Finally, the Pd, Qd, and Rd components of the device color are treated as a three-element Vector and multiplied by the inverse of MatrixPQR. The results provide the Xd, Yd, and Zd componentsof the device color in the CIE 1931 (XYZ)-space.

    As indicated by the above equations, each TransformPQR Procedure takes five operands

    <Ps or Qs or Rs: Number>

    <Bd: VectorReference>

    <Wd: VectorReference>

    <Bs: VectorReference>

    <Ws: VectorReference>

    where the operands are as described in the above equations. Each interpretation of a TransformPQR Procedure shall produce one result

    <Pd or Qd or Rd: Number>

    where the result is a monotonic function of its Number argument. Since these Procedures are called at implementation-dependent times, they must operate as pure functions — they should not depend on any non-default context and should not affect the current context.

    RangePQR

    The optional key/value pair <RangePQR: Vector> is a 6-element Vector of type Number whose elements specify the range of valid values for the P, Q, and R components. The elements of RangePQR are interpreted as three pairs of bounds, one pair for each of the three color components:

  • [ P0 P1 Q0 Q1 R0 R1 ]

    The ranges of valid values for each of the three color components are then defined as

    P0PP1, Q0QQ1, and R0RR1.

    If the RangePQR key is not present, the default ranges are:

  • [ 0 1 0 1 0 1 ]

    MatrixLMN

    The optional key/value pair <MatrixLMN: Vector> is a 9-element Vector of type Number whose elements specify the linear interpretation of the X, Y, and Z components of the CIE 1931 (XYZ)-space with respect to the intermediate LMN representation, as described in . The order of the elements in the Vector is:

  • [ LX MX NX LY MY NY LZ MZ NZ ]

    If the MatrixLMN key is not present, the default matrix used is:

  • [ 1 0 0 0 1 0 0 0 1 ]

    EncodeLMN

    The optional key/value pair <EncodeLMN: Vector> is a 3-element Vector of type Procedure whose elements are Procedures that encode the L, M, and N components of the intermediate LMN representation. The order of the elements in the Vector is:

  • [ EL EM EN ]

    Each Procedure is called with an unencoded L, M, or N value as an operand and must return the corresponding encoded value. Since these Procedures are called at implementation-dependent times, they must operate as pure functions — they should not depend on any non-default context and should not affect the current context.

    If the EncodeLMN key is not present, the default value used is a reference to a Vector of null Procedures which do not affect the contents of the operand stack:

  • [ {} {} {} ]

    The transformation defined by the MatrixLMN and EncodeLMN entries is:

    L = EL (X × LX + Y × LY + Z × LZ)

    M = EM (X × MX + Y × MY + Z × MZ)

    N = EN (X × NX + Y × NY + Z × NZ)

    RangeLMN

    The optional key/value pair <RangeLMN: Vector> is a 6-element Vector of type Number whose elements specify the range of valid values for the L, M, and N components of the intermediate representation. The elements of RangeLMN are interpreted as three pairs of bounds, one pair for each of the three color components:

  • [ L0 L1 M0 M1 N0 N1 ]

    The ranges of valid values for each of the three color components are then defined as

    L0LL1, M0MM1, and N0NN1.

    If the RangeLMN key is not present, the default ranges are:

  • [ 0 1 0 1 0 1 ]

    MatrixABC

    The optional key/value pair <MatrixABC: Vector> is a 9-element Vector of type Number whose elements specify the linear interpretation of the encoded L, M, and N components of the intermediate LMN representation with respect to the render color space, as described in . The order of the elements in the Vector is:

  • [ AL BL CL AM BM CM AN BN CN ]

    If the MatrixABC key is not present, the default matrix used is:

  • [ 1 0 0 0 1 0 0 0 1 ]

    EncodeABC

    The optional key/value pair <EncodeABC: Vector> is a 3-element Vector of type Procedure whose elements are Procedures that encode the A, B, and C components of the render color space. The order of the elements in the Vector is:

  • [ EA EB EC]

    Each Procedure is called with an unencoded A, B, or C value as an operand and must return the corresponding encoded value. Since these Procedures are called at implementation-dependent times, they must operate as pure functions — they should not depend on any non-default context and should not affect the current context.

    If the EncodeABC key is not present, the default value used is a reference to a Vector of null Procedures which do not affect the contents of the operand stack:

  • [ {} {} {} ]

    The transformation defined by the MatrixABC and EncodeABC entries is:

    A = EA (L × AL + M × AM + N × AN)

    B = EB (L × BL + M × BM + N × BN)

    C = EC (L × CL + M × CM + N × CN)

    RangeABC

    The optional key/value pair <RangeABC: Vector> is a 6-element Vector of type Number whose elements specify the range of valid values for the A, B, and C components. The elements of RangeABC are interpreted as three pairs of bounds, one pair for each of the three color components:

  • [ A0 A1 B0 B1 C0 C1 ]

    The ranges of valid values for each of the three color components are then defined as

    A0AA1, B0BB1, and C0CC1.

    If there is no RenderTable key, these ranges must lie within the range 0 to 1, since the render color space maps directly onto a device color space. If RenderTable is present, these ranges define the boundaries of the three-dimensional lookup table.

    If the RangeABC key is not present, the default ranges are:

  • [ 0 1 0 1 0 1 ]

    RenderTable

    The optional key/value pair <RenderTable: Vector> is a Vector whose elements describe a three-dimensional lookup table and associated Procedures which together map colors in render color space to colors in device color space via table lookup and interpolation. The Vector takes the form:

  • [ <NA : Cardinal> <NB: Cardinal> <NC: Cardinal> <table: Vector> <m: Cardinal>
  • <T1: Procedure> <T2: Procedure> ... <Tm: Procedure> ]

    where the dimensions of the lookup table are given by NA, NB, and NC; each of which must have an Integer greater than 1. Each entry in the table consists of m encoded color component values, where the value of m is 3 or 4. The entry at integer coordinates (a, b, c) in the table, where 0 ≤ a < NA, 0 ≤ b < NB, and 0 ≤ c < NC, contains the encoded device color value that corresponds to render color space components A, B, and C, where:

    A = A0 + a × (A1 - A0) / (NA - 1)

    B = B0 + b × (B1 - B0) / (NB - 1)

    C = C0 + c × (C1 - C0) / (NC - 1)

    and the values A0, A1, B0, B1, C0, and C1 are those given in the RangeABC entry.

    The element table must be a Vector of NA OctetStrings which define the contents of the lookup table. Each OctetString must contain m × NB × NC octets. Within the String at index a in the Vector, the m octets starting at position m × (b × NC + c) comprise the table entry at location (a, b, c). These octets are interpreted as encoded device color components e1, e2, ... em.

    The elements T1, T2, ... Tm are Procedures that transform the encoded components to actual device color component values. These transformations are:

    d1 = T1 (e1/255)

    d2 = T2 (e2/255)

    dm = Tm (em/255)

    In other words, the color rendering function treats an octet extracted from the table as an Integer, divides it by 255 (producing a number in the range 0 to 1), and pushes it on the Operand Stack. It then calls the appropriate T Procedure, which is expected to consume its operand and produce a result in the range 0 to 1. Since these Procedures are called at implementation-dependent times, they must operate as pure functions — they should not depend on any non-default context and should not affect the current context.

    The values d1, d2, ... dm constitute the final device color value. That is, if m is 3 then d1, d2, and d3 are the red, green, and blue components; if m is 4 then d1, d2, d3, and d4 are the cyan, magenta, yellow, and black components.

    Conversions among Device Color Spaces

    The device colorants used by the presentation device define a native device color space which typically corresponds to one of the color spaces DeviceGray, DeviceRGB, or DeviceCMYK. If the presentation device supports continuous-tone output, reproduction occurs directly; otherwise, it is accomplished by means of a halftone function. If a document specifies colors in the native device color space, no conversions are necessary. Otherwise, the Presentation Process must convert color values as specified in a document to the appropriate color values for the native color space of the presentation device. The conversion is performed by a color conversion function. The color conversion function is actually a set of functions, one for each colorant in the native device color space.

    Device color conversions ordinarily are not performed when a document specifies colors in CIE color spaces; the CIE color rendering functions (see 35.2) map directly to the native device color space. Therefore this clause describes only the conversions from one device color space to another. Conversions to the DeviceKX color space from other device color spaces, and from DeviceKX to other device color spaces, are not defined by this International Standard.

    The conversions described in the following subclauses do not involve the use of transfer functions or halftone functions. When colors are actually to be rendered on the media, the transfer functions and halftone functions are applied at a later stage to the output of the color conversion step.

    Conversion between DeviceRGB and DeviceGray

    Black, white, and intermediate shades of gray can be considered special cases of DeviceRGB color; the color conversion function which maps a specific DeviceGray color value gray to the equivalent DeviceRGB color value is:

    red = gray

    green = gray

    blue = gray

    The color conversion function which maps a given DeviceRGB color value to a DeviceGray color value is computed according to the NTSC video standard formula:

    gray = .3 × red + .59 × green + .11 × blue

    Conversion between DeviceCMYK and DeviceGray

    A DeviceGray color value is the complement of the black component of the corresponding DeviceCMYK color value. The color conversion function which maps a specific DeviceGray color value gray to the equivalent the DeviceCMYK color value is:

    cyan = 0.0

    magenta = 0.0

    yellow = 0.0

    black = 1.0 - gray

    The color conversion function which maps a given DeviceCMYK color value to a DeviceGray color value is essentially a conversion from DeviceCMYK to DeviceRGB, followed by a conversion from DeviceRGB to DeviceGray. These two color conversion functions may be combined and expressed as:

    gray = 1.0 - min(1.0, .3 × cyan + .59 × magenta + .11 × yellow + black)

    where min is a function which returns the minimum value from a set of values.

    Conversion from DeviceRGB to DeviceCMYK

    The color conversion function which maps a given DeviceRGB color value to a DeviceCMYK color value is defined by two sets of equations. The first set of equations express the relationship between red-green-blue and cyan-magenta-yellow. The second set of equations specify how black generation and undercolor removal are used to generate a black component and alter the other components to produce a better approximation of the original color.

    The subtractive color primaries cyan, magenta, and yellow are the complements of the additive primaries red, green, and blue; so in theory, the color conversion function should be very simple:

    cyan = 1.0 - red

    magenta = 1.0 - green

    yellow = 1.0 - blue

    Logically, cyan, magenta, and yellow are all that are needed to generate a printing color. Thus, an equal percentage of cyan, magenta, and yellow should create the equivalent percentage of black.

    Black Generation and UnderColorRemoval

    In reality, colored printing inks do not mix perfectly; such combinations often form dark brown shades instead. Thus, it is often desirable to substitute real black ink for the black portion of a color to obtain a truer color rendition. Computing the quantity of this component requires some additional equations.

    • A black generation function calculates the amount of black to be used when trying to reproduce a particular color.
    • An undercolor removal function reduces the amount of cyan, magenta, and yellow components to compensate for the amount of black that was added by the black generation function.

    SPDL provides limited control over black generation and undercolor removal when converting from DeviceRGB to DeviceCMYK color spaces. Applications requiring finer control must specify colors in CIE color spaces and control conversion to DeviceCMYK color by means of the CIE color rendering Dictionary (see ). The complete conversion from DeviceRGB color to DeviceCMYK color is as follows, where BG (k) and UCR (k) are invocations of the black generation and undercolor removal functions, respectively. The first set of equations define c, m, y and b, the initial approximation to the cyan, magenta, yellow and black values.

    c = 1.0 - red

    m = 1.0 - green

    y = 1.0 - blue

    k = min(c, m, y)

    The second set of equations use the initial approximations to compute the actual cyan, magenta, yellow and black values.

    cyan = min(1.0, max(0.0, c - UCR(k)))

    magenta = min(1.0, max(0.0, m - UCR(k)))

    yellow = min(1.0, max(0.0, y - UCR(k)))

    black = min(1.0, max(0.0, BG(k)))

    where min is a function which returns the minimum value from a set of values and max is a function which returns the maximum value from a set of values.

    The black generation and undercolor removal functions are defined as Procedures and are stored in the Graphics State Variables CurrentBlackGeneration and CurrentUnderColorRemoval, respectively. The SetBlackGeneration and SetUnderColorRemoval operators set these parameters in the Graphics State.

    The default values for the CurrentBlackGeneration and CurrentUnderColorRemoval Graphics State Variables are implementation-dependent.

    The Presentation Process calls these Procedures when it needs to perform DeviceRGB color to DeviceCMYK color conversion. Each Procedure is called with a single numeric operand and is expected to return a single numeric result. Because the Procedures may be called at unpredictable times, they must operate as pure functions, without side-effects.

    The operand of both Procedures is k, the minimum of the intermediate c, m, and y values that have been computed by subtracting the original red, green, and blue values from 1. Nominally, k is the amount of black that can be removed from the cyan, magenta, and yellow components and be substituted as a separate black component. The black generation function computes the actual black component as a function of the nominal k value.

    The undercolor removal function computes the amount that is to be subtracted from each of the intermediate c, m, and y values to produce the final cyan, magenta, and yellow components; it is expected to return values in the range -1 to 1 (inclusive). If the undercolor removal function returns a negative value, the absolute value of the returned value is added to each component. The component values that result from black generation and undercolor removal are expected to be in the range 0 to 1. If a value falls outside this range, the nearest valid value is substituted automatically, without error indication, as indicated by the min and max functions above.

    Conversion from DeviceCMYK to DeviceRGB

    The color conversion function which maps a given DeviceCMYK color value to a DeviceRGB color value is:

    red = 1.0 - min(1.0, cyan + black)

    green = 1.0 - min(1.0, magenta + black)

    blue = 1.0 - min(1.0, yellow + black)

    where min is a function which returns the minimum value from a set of values. This is a simple set of equations that do not involve the black generation or undercolor removal functions.

    Transfer Functions

    A transfer function adjusts the values of color components to compensate for non-linear response in a presentation device and in the human eye. Each component of a device color space (for example, the red component of the DeviceRGB color space) is intended to represent the perceived lightness or intensity of that component in proportion to the numeric value. Many devices do not exhibit such a linear response; a transfer function can compensate for the actual response of the device. This mapping is sometimes called gamma correction.

    In the sequence of steps for processing colors, the Presentation Process applies the transfer function after performing conversions between color spaces (if necessary) but before applying the halftone function (if necessary). A separate transfer function applies to each device color component; there is no interaction between components. Which device color components are relevant is indicated by the ProcessColorClass State Variable. Transfer functions operate in the native color space of the output device, regardless of the color space in which colors were originally specified.

    Specifying Transfer Functions

    Transfer functions are specified within a halftone Dictionary. Each transfer function is the value bound to the TransferFuntion key in an appropriate halftone Dictionary (see ). The currently active transfer functions are in the halftone Dictionary or Dictionaries that are referenced by the value of the Graphics State Variable CurrentHalftone. The value of this Graphics State Variable may be changed with the SetHalftone operator. If the device only has one device color, then there is only one halftone Dictionary referenced by CurrentHalftone. If the device has more than one device color, then there is a Type 5 halftone Dictionary with one key per device color (see 19.18.1). The halftone Dictionaries bound to those keys have the transfer functions for each device color.

    The default values of the TransferFunction keys of the halftone Dictionary or Dictionaries referenced by the CurrentHalftone Graphics State Variable is implementation-dependent.

    Transfer functions are represented by Procedures. Transfer function Procedures are executed with an operand of type Number in the range 0.0 to 1.0 (inclusive), and that must return a Number in the same range. The operand is the value of a color component in the native device color space (either specified directly or produced by conversion from some other color space). The result is the transformed value that is to be transmitted to the device (after halftoning, if necessary).

    The operand and result of a transfer function are always interpreted as if the component were additive (red, green, blue, or gray); that is, larger numbers indicate lighter colors. If the component is subtractive (cyan, magenta, yellow, or black), the Presentation Process converts it to additive form by subtracting it from 1.0 before passing it to the transfer function. The result from the transfer function is always in additive form; it is passed on to the halftone function in this form. This convention also applies to NamedColor components. Since these Procedures are called at implementation-dependent times, they must operate as pure functions — they should not depend on any non-default context and should not affect the current context.

    Halftone Functions

    Halftoning is the process by which continuous-tone colors are approximated by a pattern of pixels that can achieve only a limited number of discrete colors. The most familiar case of this is the rendering of gray tones with black and white pixels. Some devices can reproduce continuous-tone colors directly. For such devices, halftoning is not required.

    If halftoning is required, it occurs after all color components have been transformed by the appropriate transfer function. For each device pixel, the halftone function determines which of the colors the device is able to produce will be used for that pixel. The input to the halftone function consists of continuous-tone gamma-corrected color components in the presentation device's native color space. The output of the halftone function consists of a color that the device can actually render on an instance of the media. The halftone function is implicitly defined by reference to the model for halftone screens. As with most rendering controls, halftone functions are inherently device-specific, and should only be used in a document in a known local environment where extremely high-quality output requirements necessitate the use of such controls. Documents which do not require the use of halftone functions for extremely high-quality output should refrain from defining their own halftone functions, and rely instead upon the implementation-specific default halftone functions which are present in all conforming implementations.

    Model for Halftone Screens

    The halftone functions supported by SPDL are based on the use of a halftone screen. A screen is defined by conceptually laying a uniform square grid of halftone cells over the device pixel array. Each pixel belongs to one cell of the grid; a halftone cell usually contains many device pixels. The screen grid is defined entirely in device pixel space, unchanged by modifications to the CurrentTransformation; this property is essential for ensuring that adjacent areas colored by halftone functions are properly stitched together without seams.

    For a black-and-white device, each cell of a screen can be made to approximate a shade of gray by painting some of the cell's pixels black and some pixels white. Numerically, the gray level produced within a cell is the ratio of the cell's pixels that are white to the total number of pixels in that cell. If a cell contains n pixels then it is capable of rendering n + 1 different gray levels. A particular desired gray value g in the range 0 to 1 is produced by making i pixels white, where i = floor(g × n).

    The foregoing description also applies to color output devices whose pixels consist of primary colors that are either completely on or completely off. A halftone function is applied to each color component independently, producing shades of that color.

    Color component values are presented to the halftone functions in additive form, regardless of whether they were originally specified in additive (RGB or gray) or subtractive (CMYK) form. Larger values of a color component represent lighter colors — greater intensity in an additive device; less ink in a subtractive device. Transfer functions are always interpreted as if the component were additive; see .

    Generating Halftone Screens

    There are two basic methods of generating halftone screens available in all implementations:

    • The document may specify a screen frequency, screen angle, and spot function for each color component; this method is the default method for generating halftone screens and is discussed in .
    • The document may specify a Vector of threshold values to be tiled across device pixel space; these values are consulted to determine how to render intermediate color levels. This method is most useful for low-resolution devices and is discussed in .

    Spot Functions For ease of description, the explanation of this method of generating halftone screens employs as an example a black-and-white device producing gray levels. The same processes and algorithms are employed on a color device to render intermediate colors; that is, colors which cannot be directly represented on the device.

    The default method for generating halftone screens requires a screen frequency, screen angle, and spot function for each color component. The halftone screen grid has a frequency (number of halftone cells per centimeter) and angle (orientation of the grid lines relative to the device pixel coordinate system). As a cell's desired gray value varies from black to white, individual pixels in the cell change from black to white in a well-defined sequence. If a particular gray includes certain white pixels, lighter grays will include the same white pixels as well as some additional ones. The order in which pixels change from black to white for increasing gray levels is specified by a spot function, which is defined as a Procedure. The spot function describes the order of pixel whitening in an indirect way that minimizes interactions with screen frequency and angle.

    A halftone cell has its own coordinate system: the center of the square is the origin and the corners are at ±1 in x and y. In this system, each pixel in the cell is centered at x and y coordinates that are both between -1 and 1. For each pixel, the spot function Procedure is called with the coordinates of the pixel as an operand; the Procedure must return a single number between -1 and 1 that defines the pixel's position in the ordering.

    The actual values returned by the spot function are not significant; the order in which pixels are whitened is determined solely by the relative spot function values for different pixels. As a cell's gray value varies from black to white, the first pixel whitened is the one whose spot function has the lowest (most negative) value, the next pixel is the one with the next higher spot function value, and so on. If two pixels have the same spot function value, the assignment of their relative order is implementation-dependent.

    Threshold Arrays

    An alternate method of generating halftone screens is via an array of threshold values that directly control individual device pixels in a halftone cell. This method is useful on low-resolution devices because it provides a high degree of control over halftone rendering and because it permits halftone cells to be rectangular, whereas halftone cells defined by a spot function are always square.

    A threshold array is much like a sampled raster graphics image: it is a rectangular array of pixel values. However, it is defined entirely in device pixel space and the sample values are always octets. The pixel values nominally represent gray levels where 0 is black and 255 is white. The threshold array is replicated to tile the entire device pixel space; thus, each pixel of device space is mapped to a particular sample of the threshold array.

    On a bi-level device, where each pixel is either black or white, the halftone function implicitly defined by a threshold array is created as follows: For each device pixel that is to be painted with some gray level, consult the corresponding pixel of the threshold array. If the desired gray level is less than the pixel value in the threshold array, paint the device pixel black; otherwise paint it white. Gray values in the range 0 to 1 (inclusive) correspond to pixel values 0 to 255 (inclusive) in the threshold array.

    This scheme easily generalizes to monochrome presentation devices which can render multiple levels per pixel. For example, a presnentation device may be to directly render one of four different gray levels: black, dark gray, light gray, and white, on each device pixel. For each device pixel that is to be painted with some intermediate gray level that is not one of the four directly representable by a device pixel, the algorithm consults the corresponding element of the threshold array to determine whether to use the next lower or next higher representable gray level.

    A halftone function defined in this way can also be used with color displays that have a limited number of values for each color component. The red, green, and blue values are simply treated independently as if they were gray levels.

    Halftone Dictionaries

    A halftone Dictionary is a Dictionary object whose key/value pairs are parameters used to defined one or more halftone functions. The Graphics State includes a current halftone Dictionary, which specifies the halftone functions to be used in rendering. The operator GetHalftone returns the current halftone Dictionary; the operator SetHalftone establishes a different halftone Dictionary as the current one. Other operators may affect the current halftone Dictionary in the Graphics State; see .

    Every halftone Dictionary must have a HalftoneType key whose value is a Cardinal. This specifies the major type of halftone function; the remaining entries in the Dictionary are interpreted according to the type. Three types of standard halftone Dictionaries are specified in this International Standard. The following subclauses describe the standard contents of each standard type of halftone Dictionary. This International Standard describes only the mandatory and optional standard entries in halftone Dictionaries. There may be other implementation-dependent entries in halftone Dictionaries which are not defined in this International Standard.

    HalftoneType 1 Halftone Dictionaries

    A halftone Dictionary whose HalftoneType is 1 defines a halftone screen according to a frequency, angle, and spot function (see ). A HalftoneType 1 halftone Dictionary can be made the current halftone Dictionary in the Graphics State by the SetHalftone operator. The contents of a HalftoneType 1 halftone Dictionary are described in the following subclauses.

    HalftoneType

    The mandatory key/value pair <HalftoneType: Cardinal> must have a value of 1.

    Frequency

    The mandatory key/value pair <Frequency: Number> specifies the number of halftone cells per centimeter.

    Angle

    The mandatory key/value pair <Angle: Number> specifies the number of degrees by which the halftone screen is to be rotated with respect to the RCS.

    SpotFunction

    The mandatory key/value pair <SpotFunction: Procedure> defines the order in which device pixels within a halftone cell are adjusted for different gray/color levels. The Procedure takes two operands

  • <y: Number>
  • <x: Number> and returns one result
  • <relval: Real> where x and y are the coordinates of a device pixel in the halftone cell coordinate system and relval is a Real between -1.0 and 1.0 (inclusive) that defines the position of the pixel in the ordering. See for a detailed description of the semantics of spot functions.

    TransferFunction

    The mandtory key/value pair <TransferFunction: Procedure> specifies a mapping of device color values to compensate for non-linear response in the presentation device and/or in the human eye. The Procedure takes one operand

  • <d: Number> and returns one result
  • <t: Real> where d is a color value for a native device color and t is the value that will acually be transmitted to the device. See for a detailed description of transfer functions.

    ActualFrequency

    The optional key/value pair <ActualFrequency: Number> is a placeholder whose value is set by the SetHalftone operator. SetHalftone may make slight adjustments to the requested screen frequency so as to ensure that the patterns of enclosed pixels remain constant as the screen cells are replicated over the entire page. If this key/value pair is present in a HalftoneType 1 halftone Dictionary presented to the SetHalftone operator, the operator replaces its value with the actual frequency that was achieved.

    ActualAngle

    The optional key/value pair <ActualAngle: Number> is a placeholder whose value is set by the SetHalftone operator. SetHalftone may make slight adjustments to the requested screen angle so as to ensure that the patterns of enclosed pixels remain constant as the screen cells are replicated over the entire page. If this key/value pair is present in a HalftoneType 1 halftone Dictionary presented to the SetHalftone operator, the operator replaces its value with the actual angle that was achieved.

    HalftoneType 3 Halftone Dictionaries

    A halftone Dictionary whose HalftoneType is 3 defines a halftone screen as an array of threshold values that directly control individual device pixels in a halftone cell. A HalftoneType 3 halftone Dictionary can be made the current halftone Dictionary in the Graphics State by the SetHalftone operator. The contents of a HalftoneType 3 halftone Dictionary are described in the following subclauses.

    HalftoneType

    The mandatory key/value pair <HalftoneType: Cardinal> must have a value of 3.

    Width

    The mandatory key/value pair <Width: Cardinal> specifies the width of the threshold array in pixels.

    Height

    The mandatory key/value pair <Height: Cardinal> specifies the height of the threshold array in pixels.

    Thresholds

    The mandatory key/value pair <Thresholds: OctetStringReference> specifies the threshold array. The OctetString must contain Width × Height elements describing the rectangular threshold array starting at the lower left corner (viewing the rectangular array as it will be tiled onto device pixel space) and continuing in a left-to-right, bottom-to-top order. See for a detailed description of threshold arrays and the semantics of the values in the threshold array.

    TransferFunction

    The mandtory key/value pair <TransferFunction: Procedure> specifies a mapping of device color values to compensate for non-linear response in the presentation device and/or in the human eye. The Procedure takes one operand

  • <d: Number> and returns one result
  • <t: Real> where d is a color value for a native device color and t is the value that will acually be transmitted to the device. See for a detailed description of transfer functions.

    HalftoneType 5 Halftone Dictionaries

    A halftone Dictionary whose HalftoneType is 5 allows specification of individual halftone screens for an arbitrary number of color components. It contains entries whose names are device color components or NamedColor names and whose values are halftone Dictionaries.

    Which set of Names is meaningful as the set of keys for a halftone Dictonary whose HalftoneType is 5 depends on the value of the ProcessColorClass key of the value of the DeviceDescription State Variable whose definition in also specifies which device color names, also called process colorants, are relevant for each type of device color space. In the case of the NamedColor color spaces the names correspond to the names used as NamedColor parameters to the SetColorSpace operator. Each key which is the name of a process or NamedColor colorant is bound to a type 1 or type 3 halftone Dictionaries which describes the halftone and transfer function for that colorant. This is in contrast to a type 1 or typehalf 3 tone Dictionary appearing as the main halftone Dictionary (operand to the SetHalftone operator), in which case that halftone Dictionary applies to all color components.

    A HalftoneType halftone Dictionary can be made the current halftone Dictionary in the Graphics State by the SetHalftone operator. In addition to the arbitrary number of optional color name/halftone Dictionary pairs, a HalftoneType 5 halftone Dictionary must contain two mandatory entries; these are described in the following subclauses.

    HalftoneType

    The mandatory key/value pair <HalftoneType: Cardinal> must have a value of 5

    Default

    The mandatory key/value pair <Default: Dictionary> is a halftone Dictionary specifying the halftone function to be applied to any colorant that does not have its own key in the HalftoneType 5 halftone Dictionary.

    Defining Halftone Functions

    Halftone functions are implicitly defined by reference to the model for halftone screens (see ). The information used in defining the current halftone function or functions is stored in the Graphics State Variable CurrentHalftone. The value of this Graphics State Variable can be set by the SetHalftone operator. The initial value of this Graphics State Variable is specified in

    Operators

    The specification of these operators and their semantics includes the specification of conditions which may cause content exceptions to be raised as a result of interpretation of the operators. Content exceptions and exception handling are defined in In addition to the operator-specific exceptions, there are generic exceptions which may be raised during the interpretation of almost any operator. These generic exceptions and their semantics are described in .

    CIE Color Conversion Operators

    The following operators provide control over the conversion from CIE-related color space colors to device color space colors.

    SetColorRendering

    The SetColorRendering operator takes one operand

  • <crd: DictionaryReference> and returns no results. crd must be a reference to a color rendering Dictionary (as described in ). The effect of this operator is to set the value of the CurrentColorRendering Graphics State Variable to crd.

    GetColorRendering

    The GetColorRendering operator takes no operands and returns one result

  • <crd: DictionaryReference> where crd is the value of the CurrentColorRendering Graphics State Variable; the current color rendering Dictionary in (see ) the Graphics State.

    Device Color Conversion Operators

    The following operators provide control over the conversion from RGB device colors to CMYK device colors.

    SetUnderColorRemoval

    The SetUnderColorRemoval operator takes one operand

  • <ucr: Procedure> and returns no results. ucr must be an undercolor removal Procedure (as described in ). The effect of this operator is to set the value of the CurrentUnderColorRemoval Graphics State Variable to ucr.

    GetUnderColorRemoval

    The GetUnderColorRemoval operator takes no operands and returns one result

  • <ucr: DictionaryReference> where ucr is the value of the CurrentUnderColorRemoval Graphics State Variable.

    SetBlackGeneration

    The SetBlackGeneration operator takes one operand

  • <bg: Procedure> and returns no results. bg must be a black generation Procedure (as described in). The effect of this operator is to set the value of the CurrentBlackGeneration Graphics State Variable to bg.

    GetBlackGeneration

    The GetBlackGeneration operator takes no operands and returns one result

  • <bg: DictionaryReference> where bg is the value of the CurrentBlackGeneration Graphics State Variable.

    Halftone Function Operators

    The following operators provide control over the halftone function of the model for rendering.

    SetHalftone

    The SetHalftone operator takes one operand

  • <htd: DictionaryReference> and returns no results. The effect of executing the SetHalftone operator is to set the value of the CurrentHalftone Graphics State Variable to the value of the halftone DictionaryReference operand htd, and to make the referenced Dictionary readonly.

    GetHalftone

    The GetHalftone operator takes no operands and returns one result

  • <htd: DictionaryReference> where htd is a reference to a halftone Dictionary that is the value of the CurrentHalftone Graphics State Variable in the Graphics State.