Document Content Processing Model

Content processing consists of parsing the Content value and processing the resulting sequence of tokens. Unlike the structure notation, which is declarative in nature, the Content values express the document contents in the form of a procedural language to be interpreted by the Content Processor. The effect of processing a Content value is described in terms of a Virtual Machine. The Content values, and their associated Contexts of Interpretation, are identified during Structure Processing as described in . These data are then provided to the Content Processor.

The Content values identified by the Structure Processing are parsed, by the Virtual Machine, into a sequence of tokens as specified in if the Content value is in Binary Content Representation and Interchange Format and in if the Content value is in Clear Text Content Representation and Interchange Format as indicated by the content notation specifier in the Content value.

Processing the sequence of tokens consists of interpreting each token and modifying the Virtual Machine State and the Current Page Image as specified for that token. Some tokens have no effect on the Current Page Image and others may make large modifications. Defining this complex activity more precisely requires several sub models.

This Clause defines the Virtual Machine, and the imaging model, and coordinate systems. The Virtual Machine models the overall content interpretation process. The imaging model defines how the Current Page Image is modified and the coordinate system provides the frame of reference for operators that affect the Current Page Image.

This International Standard does not specify any fallback processing to be invoked when the presentation device does not have the capabilities expected of that device when the Document was composed. Such actions can be included in SPDL Documents by using content operators to test the characteristics of the device and conditionally execute content Procedures based on the results of those tests.

Virtual Machine

The Virtual Machine models the overall process of content processing. The Virtual Machine model is presented only as a model for defining the semantics of document content. It is not intended to dictate the actual implementation of a document content processor, nor to restrict the method by which document content semantics are realized in a particular implementation.

The Virtual Machine model of a document content processor consists of the following components:

shows the components of the Virtual Machine and states the subclauses in which they are specified. Virtual Machine

The remainder of this subclause is a more detailed definition of the components of the Virtual Machine. First, some concepts used in the definitions of the individual components are introduced and then the definitions of the components themselves follow.

Basic Concepts

The definitions of the components of the Virtual Machine are based on three concepts: object, state, and operator.

Objects

The data elements that can be operated upon by the Virtual Machine are objects. The class of objects is an expansion of the class of values defined in . The class of objects shall be partitioned into two sub-classes: values and composite objects. The class of values is extended with a new set of objects called object references. Where it is necessary to identify the values that are not object references, these will be called simple values. Only values, simple and object references, can be used directly as operands of content operators.

Composite objects possess properties that values do not have. A composite object has substructure; it is a multipart container which can hold values (including object references). The set of values held is called the contents of the composite object. Object references are references to other such containers. Composite objects are created by some operator or action and are identified by the object reference that results from the creation.

The semantics of a value are the same wherever it occurs. The semantics of the integer 2 do not depend on how that 2 was generated. The semantics of a composite object, however, depend on its identity as well as its content. If two object references identify the same composite object, then they are equal; otherwise they are not equal even if the content of the referenced composite objects is the same. An object reference that identifies a composite object will be said to refer to that composite object.

A composite object has visible substructure if there is some content operator that will modify a part of the composite object without generating a new object. This means that if there are two object references that refer to the same composite object, then using one as the operand of such a modifying operator will produce a change in the composite object that is visible when the other object reference is used to access that composite object. The two object references will be said to share the composite object.

Composite objects are also distinguished from values by their behavior when copied. Copying a value yields another instance of the value type which is indistinguishable from the original instance. In fact, one cannot tell whether there really is a second instance at all. If the value was an object reference, then the two object references share the same composite object.

Copying a composite object, however, requires using another container with its own identity (or creating a new container) and copying the content of the original object into the second container. These are two distinct composite objects so the references to them do not share.

Each object has a type. The types of values include some of the types defined in plus some new types. New types are introduced for the class of Composite objects. For each composite object type X, there is a corresponding XReference object reference type. The object types defined by this International Standard are specified in .

State

The Virtual Machine State consists of the Operand Stack, the Context Stack, the Graphics State Variables, the Graphics State Stack, the set of State Variables, the ordered set of SaveObjects, and the set of Referenced Objects. The Virtual Machine State consists of all but one of the components of the Virtual Machine that can be changed by content processing; the remaining component that can be changed by content processing is the Current Page Image.

The Virtual Machine State:

Operators

Operators cause actions to be taken by the Virtual Machine. These include:

Operators have zero or more operands which are:

The action that an operator takes never depends on the state of the Current Page Image prior to interpreting the operator.

Parser

The procedural input to content processing is the Content value which corresponds to a TOKENSEQUENCE that was identified by the structure processor. This Content value contains an Octet String with data in one of the two Content Representation and Interchange Formats defined in and . The parser converts the Octet String into a sequence of tokens using the rules defined in the appropriate Content Interchange Format definition ( or ) as determined by the content notation specifier in the Content value. the parser can be executed in parallel with the interpreter (see below).

Sequence of tokens

The input to the interpreter is this sequence of tokens. Each token is the object that results from the parser processing the token encoding. If a value was encoded, the result is a value; if a composite object was encoded, the result is an object reference to the composite object. In either case, the result is a value.

Some values may have an executability attribute as defined in . The executability attribute may be either literal or executable and the value is said to be a literal value or an executable value, respectively. For those values with an executability attribute, the parser, using the rules specified in and , determines the executability attribute.

In addition to interpreting content token sequences, it is possible to save a subsequence of the tokens as a Procedure. A Procedure is an executable object reference to a Vector object (see ), the elements of which are the values produced by parsing the saved tokens. Execution of a Procedure object provides an alternate source of objects to the interpreter.

Interpreter

The interpreter takes as its input a sequence of values. This sequence may either be a token sequence or the sequence of elements of an executable Vector (a Procedure). The interpreter interprets each such value in the order of the given sequence.

Interpreting a literal Identifier, a literal VectorReference, or any other type of value that does not possess an executability attribute causes that value to be pushed onto the Operand Stack.

Interpreting an executable Identifier object causes the value bound to that identifier to be interpreted. Finding the value bound to an identifier is described in the Context Stack description, below.

The interpretation of an executable Vector reference (a Procedure reference) depends on how that reference is encountered. If the reference is encountered directly in the token sequence or as an element of an executable Vector, then the encountered executable Vector reference is pushed onto the Operand Stack and is not executed. If the executable Vector reference is encountered indirectly as the result of the execution of some Identifier or Operator, then the executable Vector that is referenced is executed.

Interpreting an object of type Operator causes the Virtual Machine to perform actions that depend on the particular operator. The set of operators defined by this International Standard is defined in Clauses to . The set of operators is summarized in .

The actions resulting from interpreting an operator may include:

The actions specific to each operator are defined along with the operators in to .

Operand Stack

The Operand Stack is a stack, which may hold any number of values. It is a heterogeneous stack, in that it may hold any of the types of values in any combination. The Operand Stack is initialized from the Operand Stack in the Virtual Machine State in the Context of Interpretation passed to the Content Processor. In this International Standard, the terms stack, top of stack, push, and pop are used in a way consistent with common computer science usage.

Operators requiring values as explicit operands pop them from the operand stack, and operators which return values as explicit results push them on the Operand Stack.

Context Stack

The Context Stack is a stack of Dictionaries and is a component of the Virtual Machine State. Dictionaries (defined in ) are lists of key/value pairs in which the key is an Identifier or Cardinal and the value can be a simple value or object reference.

The Context Stack is an ordered list of Dictionaries. The initial Context Stack is taken from the Virtual Machine State in the Context of Interpretation passed to the Content Processor . A dictionary can be added to the top of the Context Stack with the PushContextStack operator. Dictionaries can be removed from the Context Stack with the PopContextStack operator. Neither UserDict nor SystemDict can be removed from the Context Stack.

The Context Stack is used to find the value bound to an Identifier. This is also known as the binding for that Identifier. When the context stack is referenced to find the binding for an Identifier, it is searched in reverse order: the last Dictionary is searched first; if the Identifier is a key in that Dictionary, then the value paired with that key is returned; otherwise, the next Dictionary is searched, and so on. If no Dictionary on the Context Stack has the Identifier as a key, then RaiseError is invoked with UndefinedKey as its operand.

The interpretation of executable Identifiers implicitly uses the Context Stack to retrieve the object bound to the Identifier. The GetValue operator can be used with a literal Identifier or Cardinal to explicitly retrieve the object bound to that key.

Standard Dictionaries

There are two standard dictionaries which occur on the Context Stack:

Set of Referenced Objects

The set of Referenced Objects is a component of the Virtual Machine State. This set consists of the set of all composite objects that were present in the Context of Interpretation or have been created by interpretation of the content, and are still referenced. A composite object is referenced if an object reference to that object is the value paired with some key in a Dictionary on the Context Stack, is on the Operand Stack, is the value of a Graphics State Variable, is the value of a Graphics State Variable saved on the Graphics State Stack, is the value of a State Variable, or if an object reference to it is a value stored in some other referenced object. The initial set of Referenced Objects is taken from the Virtual Machine State in the Context of Interpretation passed to the Content Processor.

State Variables

A set of State Variables is a component of the Virtual Machine. The State Variables are global in that they can always be referenced from content. The values of the State Variables form part of the Virtual Machine State. The State Variables and their initial values are defined in .

Graphics State and the Graphics State Stack

In addition to the State Variables there is a separate set of global variables representing the state of the imager. These are the Graphics State Variables. They act as implicit arguments to most of the imaging operators. The Graphics State Variables and their initial values are defined in . Examples include CurrentTransformation and CurrentColor. The complete set of Graphics State Variables and their values is known as the graphics state.

The Graphics State Stack is a component of the Virtual Machine State. The set of Graphics State Variables can be saved on this stack by the SaveGraphicsState operator. This saved graphics state can be restored either explicitly by the RestoreGraphicsState or RestoreGraphicsStateXCP operator, or if it is the graphics state that is part of a SaveObject, explicitly by RestoreSavedGraphicsState and implicitly by the RestoreState operator. Unlike the Operand Stack, there are no other operators which explicitly manipulate this stack. The objects on the stack are implementation-specific data objects which represent the values of the Graphics State Variables at the time the object on the stack was created. The Graphics State Stack is initialized from the Graphics State Stack in the Virtual Machine State in the Context of Interpretation passed to the Content Processor. The operators that affect this stack are defined in .

Ordered set of SaveObjects

The values of the referenced objects, the State Variables, the Graphics State Variables and the Graphics State Stack can be explicitly saved using the operator, SaveState. This operator returns a SaveObject which can later be restored, using RestoreState. All composite objects, including any subsequent SaveObjects, created after the interpretation of a SaveState operator will be destroyed when its resulting SaveObject is restored. All other composite objects will be restored to the status they had at the time the SaveState operator is interpreted.

  • The operator SaveState does not save the state of the Context Stack nor the Operand Stack. The Context Stack may be saved by transferring a copy of its contents to a Vector using the operator ContextStack. The Operand Stack can be saved in a Vector using a simple Procedure that uses the operators Count, Mark, Copy, Pop, and MakeandStoreVector.
  • The management of storage usage in an SPDL Interpreter implementation is largely left to the designer of the implementation. The operators that create composite objects and the destruction and restoration of objects during Restore establish the constraints that any storage management system shall operate within.
  • A SaveObject must be retained either on the operand stack or as a value in some referenced object if it is to be used later as an operand for RestoreState. This implies that the implementation of that SaveObject (the storage used) must be saved as part of the interpretation of any subsequent SaveState operator.
  • There is no explicit formal structure to the set of SaveObjects. However, the action of RestoreState means that there is, effectively, an ordering defined on the set of SaveObjects making them an ordered set of SaveObjects. This ordering begins with the oldest unrestored SaveObject and ends with the most recent unrestored SaveObject. Restoring a SaveObject removes that SaveObject and all the SaveObjects subsequent to that SaveObject in the ordering. The initial value of the ordered set of SaveObjects is taken from the Virtual Machine State in the Context of Interpretation. There is always at least one SaveObject in the ordered set of SaveObjects: the implicit SaveObject for the most immediately superior BLOCK.

    Imager

    The imager is the part of the interpreter that interprets the imaging operators and causes imaging activities on the Current Page Image. The imager uses the values of the Graphics State Variables as implicit operands of the imaging operators. The operators for imaging text, geometric graphics, and raster graphics are defined in , and ; additional imaging operators are defined in and .

    Current Page Image

    The Current Page Image is provided as an argument to Content Processor and may be absent. The Current Page Image is a page image. If present, the Current Page Image is changed by the interpretation of imaging operators as described below in and the changed page image is returned as a result of content processing. If no Current Page Image was provided, any imaging operators that normally perform an imaging activity when interpreted do not do so (and give no error or warning that no imaging activity was performed).

    At the beginning of processing of the content of a PAGE, the Current Page Image starts out empty. It is the responsibility of the document Content Processor to build up the Current Page Image as it interprets imaging operators. It is the responsibility of the Structure Processor to associate complete page images with instances of the presentation media as described in .

    Set of Declared Resources

    The set of Declared Resources is part of the Context of Interpretation, which is constructed during document structure processing and passed when the Content Processor is invoked. The set of Declared Resources is the set of all resources that have been declared to be available while processing the Content value supplied to this invocation of the Content Processor. The set of Declared Resources cannot be changed during content processing.

    A resource is referenced from within content by using resource-finding operators, either the generic FindResource operator or an operator specific to the given resource type. Such operators take as an operand the Name of the resource, which is the INTERNAL RESOURCE NAME bound to the resource in the RESOURCE DECLARATION. Such operators return the corresponding resource as an object on the Operand Stack. The methods for defining resources at the structure level are defined in . The semantics of the values of the various types of resources are defined in through , and through . The FindResource operator is defined in .

    Current Abort Policy

    The Current Abort Policy is taken from the abort-policy presentation parameter in the Block State of the most immediately superior BLOCK when the Context of Interpretation is constructed. The Current Abort Policy is provided in the Context of Interpretation to control the action of exception handling within Content. It is used to determine whether execution continues after a Warning occurs or whether processing of the whole document is aborted at that point. If the Current Abort Policy is dpi::abort-policy::on-warning, further processing of the Document and the Content value is aborted. Otherwise, processing continues after a Warning. The Current Abort Policy cannot be changed by content processing.

    Initial CurrentTransformation

    During content processing, the coordinate system currently in effect can be changed by content operators, see below and . The range of these changes shall be limited by the Initial CurrentTransformation which is provided in the Context of Interpretation. The Initial CurrentTransformation cannot be changed by content processing.

    Imaging Model

    The interpretation of some of the imaging operators changes the Current Page Image. Such operators perform imaging activities. Imaging activities make changes to the page image in accordance with the imaging model.

    The imaging model is a two dimensional graphics model appropriate for device independent usage, and for high quality printing and publishing needs. A page image is built incrementally by a sequence of imaging activities beginning with an initially empty page image. Each imaging activity places an image element on the page image. An imaging activity places an image element on the page image by painting ink through a mask and a clipping region, as shown in . The Current Page Image is the page image, if any, that is a component of the Virtual Machine (see ).

    There are four components to the imaging model:

    Every imaging operator that adds an image element to a page image involves an instance of each of these components: the mask is constructed by or provided to the imaging operator, the ink and the clipping region are taken from the Graphics State Variables, and the page image is the Current Page Image component of the Virtual Machine. These components are described further below. Imaging Model

    Ink

    An imaging activity causes the currently selected color in the currently selected color space to be painted onto the page image as an ink.

    The term ink refers to the color and visual texture which will be displayed by the presentation device. This International Standard defines two kinds of inks: solid inks and patterns.

    A solid ink has a single color which can be any of the colors expressible in the CurrentColorSpace, including black, white, or any shade of gray. Solid inks are logically opaque, and obscure the colors of previously placed image elements occupying the same area of the page image. Color spaces are defined in .

    A pattern need not be solid but instead consists of repeated instances of a graphic figure, the pattern cell. The definition of the pattern specifies the coordinate space in which the pattern is defined, the X and Y distances between repeated instances and a Procedure that draws the pattern cell. The pattern cell may have transparent areas. In addition, the pattern cell may itself be already colored or it may simply be a mask to which a solid color must be associated before painting with that pattern. Clause 32 has the definition of patterns.

    With the exception of the ImageRasterElement operator, the color to be painted for each imaging operator, and the color space to which it refers, are taken from the CurrentColor and CurrentColorSpace Graphics State Variables, respectively. In the case of the ImageRasterElement operator, the color space is taken from CurrentColorSpace which must not be a pattern color space. The color to be painted for each individual sample in the sampled raster graphics image that is the operand of the ImageRasterElement operator is specified by the sample value which specifies a color in the CurrentColorSpace; see .

    Mask

    The mask provides the shape of the image element. A mask may be described as the interior of a geometric path, as the area stroked by a pen following a geometric path, an instance of sampled raster graphics image data, or an instance of bitmap raster graphics image data. In addition, each reference to a glyph in a font is an indirect reference to the mask determined by the glyph representation. Geometric paths may be used to describe a wide variety of shapes, including simple convex shapes, concave shapes, or shapes with self-intersecting or disjoint boundaries. All of these types of mask may be described by imaging operators.

    The mask determines where ink is placed on a page image. Without a clipping region, ink would change the page image where and only where the mask is defined. The clipping region further limits where the page image is changed.

    Clipping Region

    The clipping region is the region of a page image upon which ink may be placed. Ink falling within the clipping region will affect the page image, while ink falling outside the clipping region will not. Thus the shape of the image element may be clipped by the clipping region.

    The boundary of the clipping region is described using the same facilities used to describe masks geometrically. Initially, the clipping region is a rectangle containing the entire imageable region of the page. However, it may be further restricted by intersection with another geometric region. Changes to the clipping region may only be undone by restoring a Graphics State which was saved before the clipping region was changed.

    The clipping region used for each imaging operator is taken from the CurrentClippingRegion Graphics State Variable. The assured reproduction area of an page image is that region of the page image upon which marks may be made. The position and size of this region with respect to the Reference Coordinate System will vary with different media and different SPDL implementations; however, SPDL provides State Variables that allow determination of its position and size (see ) during interpretation of content. The assured reproduction area is the default CurrentClippingRegion for a page image that is associated with a given medium, and is always within the extents of that medium.

    Page Image

    The page image is an abstract, device independent model of the page that is to be rendered on a medium. A page image is built incrementally by sequentially adding image elements to an initially empty page image. An image element is the result of a single imaging activity. Imaging activities defined in this International Standard include painting

    through the CurrentClippingRegion onto the page image. The construction of an image element and any other effects of imaging operators do not in any way depend on the content or the state of that page image at the time the imaging operator is interpreted.

    Coordinate Systems

    The content imaging operators are all interpreted in the context of a current User Coordinate System. This coordinate system is defined in terms of a Reference Coordinate System established by the Structure Processor in . The relationship of the current User Coordinate System to the Reference Coordinate System is established by the CurrentTransformation Graphics State Variable. The Initial CurrentTransformation for each PAGE is established by the Structure Processor in . In addition, the CurrentTransformation in effect when each subordinate PICTURE on the page is processed is saved as the Initial CurrentTransformation for that BLOCK and is passed as the Initial CurrentTransformation in conjunction with the content processing for all TOKENSEQUENCES immediately subordinate to that BLOCK. This Initial CurrentTransformation establishes a coordinate system in terms of which all coordinate transformation within that BLOCK are relative.

    Locations within the Reference Coordinate System or the User Coordinate System are given either by separately specifying the X and Y coordinates of the location, or in terms of a point. A point is a pair of values in which the first value is the X coordinate of the location and the second value is the Y coordinate of the location.

    Reference Coordinate System

    The Reference Coordinate System (RCS) provides for unambiguous specification of locations on a page image.

    The RCS is a two dimensional Cartesian coordinate system with units of millimeters on both axes. The positioning of the RCS on the Current Page Image is specified in 16.8.

    User Coordinate Systems

    A User Coordinate System (UCS) provides for specification of locations on the Current Page Image in a flexible way.

    All position information used by imaging operators is initially specified in terms of a UCS, and a mapping from the UCS to the RCS. The mapping performs two functions:

    This mapping is provided by the CurrentTransformation Graphics State Variable. The CurrentTransformation can specify any mapping of the UCS into the RCS that can be represented in the form:

  • x' = a×x + c×y + e
  • y' = b×x + d×y + f where a, b, c, d, e, and f are real number constants whose dimensions are millimeters, x and y are coordinates in the UCS, and x' and y' are coordinates in the RCS. This is equivalent to the matrix equation

  • [ x' y' 1 ] = [ x y 1 ] × ace bdf 001

    Any such mapping where a × d - b × c = 0 will be degenerate and non-invertible.

    The set of all transformations expressible in terms of the six numbers a, b, c, d, e, and f is the set of affine transformations and includes all combinations of scaling, translation and rotation. The effect of the CurrentTransformation is to map an image element defined in UCS Space to an image element that is defined in RCS Space and can be added to the Current Page Image.

    The operators which create transformation objects (suitable for assigning to the CurrentTransformation Graphics State Variable) are defined in .

    Initial CurrentTransformation

    At any instant in time during content processing, the CurrentTransformation is logically composed of two parts: the Initial CurrentTransformation for the most immediately superior BLOCK to the content being processed and the Active CurrentTransformation. The Initial CurrentTransformation is established by the Context of Interpretation. The Active CurrentTransformation is the product (by matrix multiplication) of the CurrentTransformation times the matrix inverse of the Initial CurrentTransformation. Content processing can only change the Active CurrentTransformation; it can never change the Initial CurrentTransformation.

    The operators of which affect the CurrentTransformation are of two forms. The first form of operator computes a new CurrentTransformation relative to the existing CurrentTransformation and installs the result as the new CurrentTransformation. The second form of operator computes transformations as abstract entities which can either be appended to the CurrentTransformation using the Concat operator or installed as the Active CurrentTransformation using the SetTrans operator.

    Notation

    Literals

    Literals are single tokens or sequences of tokens that stand for an object. Except for operator names, literals within this International Standard shall be represented using the syntax for token sequences in the Clear Text Content Interchange Format defined in . The representation of operator names is given below in .

    <sl> <li> 0.5 <li> 2 <li> &lsqb;0 0 0 &rsqb; </sl>

    Objects

    An object is identified by both its type and its content. The content of a value is just the value itself. The content of a composite object is the set of values of which it is composed. The content may be denoted either by a literal for the value or by a name representing any of the possible values of the designated type. An object of type Type and whose content is denoted by Content is denoted by < Content: Type >.

    When the content is denoted by a name, which may be written in a mixture of upper and lower case letters, the name is italicized.

    <sl> <li> &lt;<hp1>n: Number </hp1>&gt; <li> &lt;<hp1>flag: Boolean </hp1>&gt; <li> &lt;<hp1>T: Transformation </hp1>&gt;</sl> When the content is a specific value or composite object it is denoted by a literal for that value or composite object. Normally such literals are not italicized. <sl> <li> <0.5:<hp1> Number </hp1>&gt; <li> <2:<hp1> Integer </hp1>&gt; <li> <&lsqb;0 0 0&rsqb;:<hp1> Vector </hp1>&gt;</sl>

    Dictionary keys, although literal identifiers, are normally italicized to identify them as part of the SPDL language and to distinguish them form the English words used to describe SPDL. This includes the names of interpreter errors in ErrorDict.

    When the type of a object is implied by the content and there are a number of such objects in close proximity, the content literal may stand alone, without its associated type, as in the last example above.

    Object Types

    An object type is denoted by a type name which is expressed by a string of italicized characters that begins with an uppercase letter and continues with lowercase letters, except that the initial letter of each word in a compound type name is an uppercase letter:

    <sl> <li> <hp1>Number</hp1> <li> <hp1>Transformation</hp1> <li> <hp1>VectorReference</hp1></sl>

    Abbreviated Forms

    When it is not necessary to specify a specific object or give it a name, an object may be denoted by the name of the type of the object in non-italicized text:

    <sl> <li> Number <li> Transformation <li> VectorReference</sl> When an object whose content is denoted by a name is referred to several times in the same subclause and the context provides enough information to avoid ambiguity, the object may be denoted solely by the name of the content.<sl> <li> "<hp1>n</hp1>" and "<hp1>T</hp1>" may be used to make repeated references to "&lt;<hp1>n: Number </hp1>&gt;" <li> and "&lt;<hp1>T: Transformation </hp1>&gt;".</sl>

    Sequences of objects

    A sequence of objects is denoted by a parenthesized, comma-separated list of object representations.

    <sl> <li> (Integer, Integer, Integer) <li> Is a sequence of three objects all of type <hp1>Integer</hp1>.</sl>

    A sequence of an indefinite number of objects is denoted by a parenthesized, comma-separated list of object representations in which the ellipsis, . . ., is used.

    <sl> <li> (<hp1>value</hp1><f><SUB>1</SUB></F>, <hp1>value</hp1><f><SUB>2</SUB></F>, . . .<f>value<SUB>n</SUB></F>) <li> Is a sequence of <hp1>n</hp1> objects named <hp1>value</hp1><f><SUB>1</SUB></F> through <hp1>value</hp1><f><SUB>n</SUB></F>. </sl>

    Operators

    An operator is denoted by an operator name expressed as a string of boldface characters that begins with an uppercase letter and continues with lowercase letters, except that the initial letter of each word in a compound operator name is an uppercase letter. The names of operators are given in .

    <sl> <li> <hp2>Multiply</hp2> <li> <hp2>FindResource</hp2> <li> <hp2>ImageRasterElement</hp2> </sl>

    State and Graphics State Variables

    A State Variable or a Graphics State Variable is denoted by its name which is expressed by a string of italicized characters that begins with an uppercase letter and continues with lowercase letters, except that the initial letter of each word in a compound variable name is an uppercase letter. The names of all Graphics State Variables are compound names in which the initial word is Current:

    <sl> <li> <hp1>CurrentColor</hp1> <li> <hp1>CurrentTransformation</hp1> <li> <hp1>CurrentClippingRegion</hp1></sl>

    Operand Stack

    When it is necessary to represent information about the state of the top portion of the Operand Stack, that state is represented by showing the top n values on the Operand Stack as a vertical list. The top value on the Operand Stack is given as the first item in the list, the second value as the second item, and so forth. The format is shown below:

  • <value1: Any > operand on the top of the stack
  • <value2: Any > second value on the operand stack
  • . . .
  • <valuen: Any > nth value on the operand stack

    It is understood that an arbitrary number of additional values may be below the shown values on the Operand Stack. Those values that are not shown are not affected or used by any operator that acts on the shown portion of the Operand Stack.

    Operator descriptions

    For each operator in this International Standard, the operator description specifies

    • the number and types of operands which are popped from the Operand Stack at the beginning of the interpretation of the operator.

    • the number and types of the results pushed onto the Operand Stack upon completion of the interpretation of the operator.

    • the relationships between the operands and the results.

    • any other effects the interpretation of the operator has upon the Virtual Machine State.

    • any effects upon the Current Page Image.

    The list of operands and the list of results are given as Operand Stack state representations.

    The description of the effects of interpreting an operator may be given solely in terms of a textual description or the text may include a sequence of SPDL tokens whose interpretation would produce an equivalent effect. The notation

  • { sequence-of-tokens }
  • stands for the result of interpreting the sequence of tokens within the curly braces. In this case, the tokens will be separated by spaces and will be represented by operator names or literals. Comments may be included within the sequence of tokens. Such comments are separated from the tokens by a percent sign (%) and continue to the end of the line.