Video & Printer Standards Reference Manual

1.6.1 The Graphics Pipeline

The state of the art in computer graphics layers the graphics environment in a manner very much like the way networks and communications models are layered. In layered models, higher level layers request services of lower levels to effect actions. Traversing these layers is known as proceeding through the graphics pipeline.

Existing proposals postulate levels for modeling of graphics information and performing viewing operations on the data represented in these models. The level of graphics execution is added to these levels. It is this level that most closely approaches the capabilities of existing graphics devices (as opposed to systems), and it is to this level that ReGIS is directed.

1.6.2 The System Model

Figure 8-1 illustrates the assumed general block diagram of the graphics system for which ReGIS was designed. As illustrated, the system consists of two major parts: (1) the host computer system, which from the user's point of view consists of various software modules and (2) the remote graphics device. The term "remote" here refers to the assumption that the graphics device is attached to the host computer by a possibly low-speed communications link.

The host computer system is assumed to consist of four major parts (not all of which may be present in any particular system):

1. Graphics application package - Such packages allow the user to access the graphics capabilities of the remote device in terms of syntax and semantics appropriate to the user's intended application. For example, a data plotting package may accept tables of data and allow the user to construct plots of varying types based on that data, using an interaction dialog appropriate to the application.

2. High level language - Users often need to generate graphic images of significant complexity requiring algorithmic definition, or images requiring dynamic changes. Such programs are generally written in higher level languages which may or may not have direct access to graphics functionality.

3. Text files - Sometimes called the graphics "metafiles"; static storage of the definition of a graphic image allows later use of that graphic image in the same manner as printing out a report file of standard text.

4. Operating system - The operating system may provide support to the graphics user in the general case by converting the graphic image definition provided by the other software to the required protocols necessary to drive one or more remote graphics devices, or may use graphics directly to implement a pictorial (iconic) dialog with the user.

1.6.3 Graphics Language Access Points

Based on the above assumed structure, the system has at least six language access points of interest to the users and developers of such a system:

1. Graphics application languages - such as plot commands in a data plotting package or the constructors of physical images as represented by the Graphical Kernel System (GKS) graphics standard.

2. High level languages - allow access to graphics semantics in three possible ways:

   1. By direct drive of character based communication protocols by using string constants output through "PRINT" statements

   2. Through graphics subroutines accessed by programmed calls

   3. Through embedded graphics statements accessed in the same manner as other language capabilities

3. Graphics text files - the syntax of how the graphics image is stored as text for later communication to the graphics device (metafiles).

4. Communications Interface - the syntax of the graphics commands sent sequentially to the graphics device.

5. Graphics hardware instructions - the (presumably digital) signals generated by the local device processor to control the hardware image generator.

6. User graphics entries - the specialized entry sequences for local control in addition to the syntax of the user commands required to use the application software programs.

1.6.4 ReGIS Scope of Application

Considering the breadth of graphics applications and the differences in "personality" between the different language points, it is not feasible to identify or specify one instruction set which satisfies the requirements of all access points in the system. On the other hand, the relatively large number of different graphics language syntaxes of which a user may have to be aware predicates a few standardized language approaches, with special languages applied when dictated by the application. These latter special applications must be based, where possible, upon other existing standards. It is the purpose of ReGIS to standardize the syntax and semantics of the communications interface graphics commands. By extrapolation, it is also intended that ReGIS be used at other graphics language access points at which a character based descriptive representation of the graphic image is appropriate. In summary then, it is intended that ReGIS be used for the following graphic language access points for both remote and closely coupled graphics systems:

1. Graphics instruction string constants from high level languages, whether generated by print statements or the compilation of high level language programs having embedded graphics statements

2. The "semantic protocol" for graphics access across a serial communications line to a remote graphics device

3. The syntax of graphics commands when stored in a character oriented file

2.1.1 Application Free Primitives

ReGIS implements a set of drawing primitives based upon common geometric rule and compass constructions, and does not contain any specific capabilities which can be interpreted in terms of the semantics of the application. For example, ReGIS does not include viewing transformation, hidden line removal, and other capabilities generally useful in presenting images of real physical things. Neither does it have built-in axis and bar graph primitives which would be used to support only data plotting. Instead, this model assumes that these capabilities are adequately supported at higher levels in the graphics pipeline, and that these functions are encoded into a sequence of ReGIS instructions. In this way, ReGIS does not burden one application with features required specifically for another.

2.1.2 Mandatory Base Implementation

ReGIS instructions are based on a general instruction syntax which all devices are required to parse.

Every device using the ReGIS instruction set must completely interpret all possible character sequences defined by this general instruction grammar, whether or not those character sequences have semantic meaning in the device in question. The syntax of ReGIS is complete and well formed. Only the semantics can vary among devices of differing capabilities, and, at that, only among extensions to the most fundamental required instruction set.

Semantically, ReGIS instructions and parameters are separated into a Base ReGIS category, a Raster Extensions category, and Open Extensions. Other extensions may be defined to apply to other technologies or categorizations. It is assumed that most of the essential information content of any desired graphic image may be defined by the Base ReGIS instructions and parameters. All ReGIS based graphic devices must accurately interpret these Base capabilities.

In addition, users expecting to output the defined images to a variety of devices should use only the Base ReGIS capabilities to ensure maximum transportability. For example, color is not a common attribute of every graphic device, and for this reason the ReGIS Base is "color-blind". Users desiring maximum transportability should avoid using color to relate essential information where that same information is not also implied by monochrome boundaries or patterns.

There are several possible categories of Standard Extensions to ReGIS. These extensions are based on differences in technology, and are used to standardize device features across the class of devices represented by that technology. The most important extension class is for raster scan display devices, including color CRT displays. Standard extensions for a given class of device allow all devices within that class to be controlled in a class dependent, yet device-within-class independent manner. Hence, all raster devices must implement the full range of the standard Raster Extensions.

This concept works, and even allows commands from an extension set to work on simpler devices, because all devices must fully parse the general instruction syntax. Therefore, a capability in one of the extension sets is simply ignored or transformed to an alternate attribute in a device for which that capability does not exist.

This approach is feasible because of the small number of syntactic elements in ReGIS, and their ease of identification.

2.1.3 Critical Device Parameters

The third major concept in allowing maximum image transportability is the use of critical setup parameters defined once for each image and placed at the beginning of the instruction sequence for that image definition. Thus, in the worst case, the user might have to adjust these parameters to achieve maximum fidelity in the reproduction of a graphic image. As an example of such a critical device parameter, ReGIS allows the user to set the range of (X,Y) coordinates to be used for an image definition. These should be set to the actual physical range values of the device which the user most often accesses. These range parameters could be adjusted to maximally utilize a dissimilar low resolution device but would not have to be adjusted for displaying the same image on a high resolution device.

Imposing expectations on the device departs from what has been common practice in graphics and other areas of computer peripheral access. Commonly, devices are interrogated for their function sets and features, and the applications take on the burden of manipulating data to fit the device. By placing the burden of accommodation on the device, the application or picture file becomes more portable and less likely to require modification as new devices or classes of devices come into use.

2.1.4 Fidelity of Information Presentation

Devices must be allowed varying levels of fidelity in the presentation of information implied by ReGIS instructions. This is a reflection of differences in technology and engineering constraints in product implementations. Fidelity may be measured in a qualitative and quantitative sense. Qualitatively speaking, a line is a line because it appears to connect two points in the display in a continuous fashion. A circle is a circle because it is "round." These aspects of fidelity are, in part, subjective. Pixel oriented devices actually draw lines as a sequence of intensified dots, and the ragged nature of some lines is entirely unpleasant in some instances. However, even these less than perfect lines are, qualitatively speaking, lines.

When fidelity is measured quantitatively, some features of some systems cannot be satisfactorily transported. Display resolution varies from device to device, and the capacity of a display in terms of discernible line pairs or character cells will vary, as will capacities of character cell stores or attribute memories. Where such limits can be quantitatively described, they will be specified with the appropriate instructions as guides to transportability.

Lower resolution and/or monochrome devices by their nature have limited information presentation capacity. Drawing a very detailed image whose information content exceeds the information capacity of the target device may result in essential information being lost. These devices may conform to the ReGIS standard if the qualitative judgement is that they will serve to display images which preserve "enough" information content for normal use. While this definition may appear quite open and perhaps circular, it is a pragmatic and workable one when the decision as to whether ReGIS is the appropriate graphics support mechanism is well-founded. Higher resolution devices may be expected to implement the highest degree of fidelity of information presentation.

Transportability is achievable if images are prepared on lower resolution devices for later output on higher resolution devices, or that a high information content image is prepared directly for the high resolution device. It is not expected that an image prepared on a high resolution device will be drawn on a substantially lower resolution device, except perhaps for "quick checking." Should this situation exist, however, the user must be willing to accept the possible misinterpretation of information as a result of the lower fidelity of reproduction.

2.2.1 Character Codes

All ReGIS commands may be formed from characters in columns 2 through 5 of the ASCII code chart. It may be considered, in light of strict interpretation of ANSI character set and coding rules, that ReGIS is a violation of the use of printing character codes for commands. This compromise achieves two goals:

1. To allow an encoding more terse than that required by existing control code standards (ANSI X3.41 and ANSI X3.64)

2. To develop an instruction set which could be easily generated, stored, and interpreted

As a matter of convention, ReGIS is defined in terms of upper-case letters with the understanding that lower-case letters are equivalent to upper-case for command interpretation. Lower-case letters remain lower case within quoted string arguments, however.

2.2.2 7-bit Versus 8-bit Encoding

The ReGIS command syntax and semantics are specified for use in a 7-bit coding environment, though provision has been made for the support of 8-bit encoding of character arguments. See subheadings 8.4.3 Argument Types, 8.4.3.2 Quoted Strings. Support of ReGIS command codes in an eight bit environment is an environmental issue, and is not addressed in this standard.

2.2.3 ASCII Control Codes

ReGIS does not specify the use of any ASCII control codes, except for certain occurrences within quoted text strings. Any controls or control or escape sequences passed to a ReGIS interpreter are not required to be recognized or parsed by the interpreter ¹. Such controls may be included in a ReGIS data stream for purposes of control of the system or device in which the interpreter is running (such as XON/XOFF for communications synchronization or escape or control sequences to activate or deactivate the ReGIS interpreter) but the recognition and interpretation of such sequences is not required by this standard for conformance.

1. Some devices find it appropriate to scan for and parse escape and control sequences while interpreting ReGIS. Some of these devices execute escape sequences as if they (the devices) were not in ReGIS mode, and return to ReGIS mode after such execution. Other devices use the occurrence of any escape code (code position 1/11 or 8/* or 9/*) as reason to exit the ReGIS mode. Such use may be necessary to support non-conforming software, but such use is deprecated by this standard.

2.2.4 Linguistic Relationship to Higher Level Languages

The ReGIS general syntax is based on a simple, easily parsed grammar. This grammar can be easily generated by common high level languages and user application packages. Also, the ReGIS instructions encompass most, if not all, of the graphics primitives required to support the execution of graphics constructs required by higher level graphics applications packages.

The encoding of ReGIS instructions and arguments is such that the use of ReGIS directly in the PRINT or WRITE commands of such languages as BASIC, FORTRAN, and Pascal is practical and straightforward. The representation allows reasonably clear, although admittedly terse, coding. In particular, numeric arguments are encoded as the usual decimal integer, fixed point, floating point, and scientific notation strings generated by these languages.

2.2.5 Algorithmic Relation to Higher Level Languages

ReGIS is not meant to be a language in its own right. ReGIS has no algorithmic structures, such as conditional or loop constructs, no general arithmetic capability, and no named variable storage. All these features are presumably present in the higher level languages from which ReGIS may be used for the encoding of pictorial information.

2.2.6 Communications Line Efficiency

The level of ReGIS instructions is set high enough so that reasonable performance can be obtained even at low transmission rates. A relatively few command characters can invoke fairly complex graphics activity. The "macrograph" construct is included in the ReGIS Base to allow string sequences to be transmitted once, stored locally, and then referred to by name for subsequent, repeatable invocation.

ReGIS is generally free format and requires no instruction separators, thereby allowing multiple instructions per "line." In fact, ReGIS has no awareness of line boundaries, since ASCII control characters are ignored (except for a few instances, and only within quoted string arguments).

2.2.7 High-level Language "Personality"

Although it is not possible to define a completely compatible personality among all higher level languages, ReGIS has attempted to capture the essence of the personality of many higher level languages to allow the most rapid learning by users with minimal corruption of well-known syntactic constructs. Common numeric and string constant constructs, the ignoring of blanks and auto-conversion of lower case to upper case are examples of the implementation of this concept.

2.3.1 Range of Devices

The ReGIS Base defines a logical graphics device modeled after a composite of existing and envisioned graphics execution devices. The common capabilities of flat bed and rotary plotters, storage tube devices, raster video and hard-copy devices, and other devices were evaluated in the definition of the command complement of ReGIS. The ReGIS Base defines a common denominator of these devices, and the Extensions categories are defined to access the unique capabilities of these and other graphics devices.

2.3.2 Position Addressing

A specific point in the viewing area of a graphic device is assumed to be representable by an (X,Y) (horizontal-vertical) pair of numbers. It is also assumed that the viewing area is rectangular in shape for the purpose of code transportability. The size of an address increment is defined by the coordinate space as imposed by the device setup, or by device default if this setup is not used.

2.3.3 Semantic Defaults

In the ReGIS Base, all parameter ranges required by a device are derivable from user supplied screen coordinates. These are transformed to physical coordinates by the device. An exception to this is the size of "standard characters" in the device. These are typically constrained by the physical design of the device. To accommodate such variances, ReGIS allows the user to "adjust" some of these parameters so that the actual visual result is as close as possible to what is desired. Such adaptations may require user intervention (that is, trial and error) to reproduce picture content accurately.

Devices that implement ReGIS extensions are required to implement default values for all such semantic features that affect the visible display. These defaults must approximate, to the degree possible, the visual impression of the image on a device without these visual enhancements. These defaults must be assumed each time the screen addressing operation, S(A[][]), is performed.

4.3.1 Bracketed Coordinate Specifier

A sequence of characters enclosed in the bracket characters ([]) refers to an (X,Y) position argument or increment. The contents of a bracketed extent are always numeric and there is no nesting of brackets. Any non-numeric character other than a comma encountered within a bracketed position argument causes the part (x value or y value) being decoded to be terminated and interpreted as not present. If more than two parts are encountered within one pair of brackets (that is, more than one comma is present), only the first two parts are accepted; the third and any subsequent parts are ignored. See subheading 8.4.3.3 Numerics.

4.3.2 Quoted Strings

A sequence of characters beginning with the single quote character (') or the double quote character (") and ending with a quote character of the same type is a text string and treated as a single argument. The contents of a quoted string are entirely arbitrary. Once the opening delimiter is seen, all following characters are interpreted literally until the string is terminated by the matching quote character.

ReGIS allows 8-bit encoding of character arguments within quoted strings. Legal character codes are 2/0 through 7/15, and 10/0 through 15/15 (two 96 character sets, 192 characters total). The accessibility of codes 7/15 and 15/15 is not guaranteed because of their interpretation as control characters in some environments. Provision for them must be made in alphabet storage, however.

The quote characters themselves are not part of the text string; a string which is introduced by a quote of one type is not terminated by a quote of the opposite type. Therefore, a quote of one type can be included in a string by using the quote character of the other type as the string delimiter.

Should it be required to include a quote character of a given type within a string delimited by quotes of the same type, the target quote character must be doubled, that is, repeated in place without any intervening characters. For example,

• "A" encodes the string A
• '"' encodes the string "
• "'" encodes the string '
• 'a''C' encodes the string a'C
• '''' encodes the string '
• "A'""B" encodes the string A'"B
• "" encodes the empty string

ReGIS instructions may have multiple string arguments. Consider, however, that if 'ABC' and 'DEF' are two consecutive string arguments, then the resulting structure is 'ABC''DEF', which will be treated by ReGIS as the single string ABC'DEF. This undesired result is avoided by separating possible consecutive string arguments with the comma character.

A potential ambiguity arises in the case of doubled quotes separated by control characters. Outside of quoted strings, all control characters and SPACE are treated as "no character" by ReGIS. Within quoted strings used as arguments to the Text command, the controls BACKSPACE, CARRIAGE RETURN, LINE FEED, HORIZONTAL TAB, and SPACE have meaning.

Should paired quotes within a set of paired quotes be separated by BS, CR, LF, HT, or SP, then they are NOT considered doubled, and two quoted arguments are recognized as if they had been separated by a comma. When separated by other controls, these controls are interpreted as "no character" and the quotes are considered doubled, forcing the inclusion of one of the quotes in the string argument. Hence, if in the command stream

T"text"<>"moretext"

the token <> were replaced by one of SP, BS, HT, LF, or CR, then an equivalent command stream would be

T"textmoretext"

because of the resulting doubled quote. Were <> to be replaced by any other control, an equivalent command stream would be

T"text""moretext"

resulting in the effective text argument

text"moretext.

Were <> to be replaced by a macrograph definition (which is specified not to disturb the state of the parser, but which is not allowed within quoted strings), the quotes are NOT doubled. The result is, again, as if the two quoted extents were separated by a comma. The macrograph definition would succeed, but would have the side effect of acting like a supported control character.

4.3.3 Numerics

Digit characters represent either numbers or sequences of arguments where each argument is a single digit character. The distinction between such uses is semantic, not syntactic and is distinguished by context. The ReGIS grammar allows numeric information to be skipped when the context is not known to an implementation. Digit strings may have semantic meaning as numbers, and integer, fixed point, floating point, and scientific notation formats are accepted.

The allowable alphabet for numeric representation is composed as follows:

• Digits zero through nine

• Plus and minus signs

• Decimal point

• The letter "E" or "e", for scientific notation

The composition of these elements into numbers is by common rules. A simple BNF-like expression of the allowed format for these numbers is

<number>    ::=  [+|-] <unsgnreal> [<exponent>]
<unsgnreal> ::=  <digits>* [.] <digits>+
               | <digits>+ [.] <digits>*
<exponent>  ::=  E[+|-]<digits>+

In this expression format, "|" means OR, "::=" means production, "<token>*" means zero or more instances of <token>, "<token>+" means one or more instances of <token>, and [] enclose optional constructs. In words, this means that a number consists of:

• A string of one or more digits, with an optional decimal point placed either before, after, or within the string, this string being

  1. optionally preceded by a single sign character, AND

  2. optionally followed by an exponent comprising

     1. the letter "e" (upper or lower case),

     2. followed by a string of one or more digits, optionally signed.

Any character other than those noted as legal numerics terminates the scan, and the accumulated numeric extent is taken as complete.

The character causing the termination is rescanned as part of the next token following the number. Consecutive numeric arguments must be separated by commas to ensure proper decoding.

The results of encountering an apparent numeric which violates the above grammar (such as having more than one sign character, more than one decimal point, a sign character or decimal point with no digits, or more than one exponentiation operator (E) within a single numeric token) are not specified in this standard, and such occurrences must be considered an error with device-dependent recovery.

The inclusion of the letter "E" in the numeric alphabet may create ambiguity in certain instances of consecutive arguments. The construct X(Y1E2) could be a legal specification of the (hypothetical) X command with quantified options Y and E, having values 1 and 2, respectively. Because of the use of the letter "E", the above construct could also be interpreted as the X command with a quantified option of Y with a value of 1e2, or 100. A ReGIS interpreter must always interpret the letter "E" numerically where such use is conceivable in context.

Hence, as shown, the interpretation of (Y1E2) would be as (Y100). Note that (Y1E2E3) would have to be interpreted as (Y100,E3), since the numeric grammar precludes the interpretation of a second exponentiation operator in a single numeric.

ReGIS generators must always precede the "E" character with the option-separating comma when there is any chance of a semantic error.

Where digit strings are used as pixel vectors described under subheading 8.4.5.3 Pixel Vectors, the sign characters and the decimal point are ignored without effect, and the interpretation of the digits takes place normally. Any other character terminates the digit string scan, and the scan state changes to that indicated by the non-digit character. This is also true of the letter "E", which, although normally valid in numerics as an exponentiation operator, must be interpreted as a keyletter at the current option level.

4.3.4 Options

Sequences of characters enclosed within the parenthesis characters "(" and ")" represent instruction options. The syntax of each option is the same as the syntax of a ReGIS instruction, including the four argument types. The option syntax is thus fully recursive, allowing theoretically infinite extensibility of ReGIS semantics. The components of all the arguments types are the same within options as they are at the command level.

For readability, options, also called sub-instructions, may be separated by comma characters but not by the semicolon character. The semicolon character terminates the instruction to the highest level.

ReGIS interpreters must be prepared to accept recursion of options to at least six levels. A conforming ReGIS generator must not exceed this level of recursion. Recovery from an attempt to exceed allowable recursion depth is to the highest command level, just as if a semicolon character had been encountered.

The hypothetical command

X(A(B(C(D(E(F))))))

represents the deepest legal nesting of option levels. Any argument type applied to suboption letter "F" other than another option level would be properly interpreted. Suboption "E" could legally accept other suboptions, as well.

Unless otherwise specified in the body of the option description, option settings are modal, that is, they represent a change of state which is maintained across commands until explicitly changed by resetting the option or by the side effect of another action. Coloquially, such options are referred to as "sticky".

Some options, particularly in the Curve instruction and all of the temporary Write options, are "volatile." They remain in effect only for the duration of the command in process. These options revert to their default state (or to their previous modal state, if applicable) when a new command keyletter or a synchronization operation is processed.

All commands whose actions reference state set by the Write options command, W, may include W as an option, and may set any W-settable state for the duration of that command. The W-state previously in force (set by a W at the top command level) is saved when the option W is encountered, and is restored when the current command is terminated by synchronization or the occurrence of a command keyletter. Such option level state is always volatile.

4.5.1 Position Argument

A position argument is delimited by a pair of left/right square brackets, both of which must be present. A position argument consists of an x-position part and a y-position part, either or both of which may be missing. The x part precedes the y part. Each component is made up of numbers, following the rules for numbers as standalone arguments. The y part, if present, is separated from the x part by a comma. See subheading 8.4.3.4 Numerics.

Each coordinate part consists of a number possibly preceded by a plus or minus sign ("+" or "-"). If a coordinate part is not preceded by a sign character, that argument represents an absolute coordinate; the value of the coordinate part is the new number, irrespective of the value of the current drawing position. If a coordinate part is preceded by a sign character, then that part is evaluated relative to the current drawing position value. A position argument may have one coordinate part as a relative specifier and the other coordinate part as an absolute specifier.

If a coordinate part is missing, that part is interpreted to mean +0, which is a relative specifier indicating a displacement of 0. Note that +0 is a different specifier from 0, which is an absolute specifier.

For each example below, assume the initial values of X and Y are 100 and 50 respectively.

4.5.2 Use of Bracketed Extents for Non-Positional Information

Some ReGIS commands are defined to use the square brackets to enclose non-positional information, as for specification of positional information not coupled to the current drawing position or to the imposed coordinate space in effect. Some uses are for expression of rectangular extent, others are for situations where "position-like" information is required.

The following uses of bracketed extent are non-positional.

In Base ReGIS:

1. S(A[][]) - The contents of the bracketed subarguments define the imposed address space. They have no dependence on current position, and signed values are interpreted as absolutes. Negative values for imposed coordinate space are not allowed. Missing values (fewer than two bracketed extents or unspecified values within the brackets) result in illegal specification.

2. T[] - Character escapement for the text command is measured in the imposed coordinate space, but these values are always interpreted as relative to the current position, even if the provided values are unsigned. Omitted values are interpreted as spacing of +0.

In Raster extentions to ReGIS:

3. T(M[]) - The storage cell multiplier is not positional, but the two elements are an ordered pair of multipliers.

4. T(U[]) and T(S[]) - The Unit and Display sizes of character cells are measured in the imposed coordinate space, but do not relate to current position. Missing values default to values associated with standard size characters.

5. L[] - The storage size of a character is measured in technology-dependent units, usually bits of storage. There is no association with current position; missing values are interpreted as 0.

In Open extentions to ReGIS:

6. S(H(P[])) - The hard-copy offset is not coupled to current position. Its relationship to the imposed coordinate space is implementation- and retransmission protocol- dependent. Missing values are interpreted as 0. The bracketed arguments to the H option itself ARE positional, do relate to the imposed coordinate space, and may be expressed in terms of the current position.

4.5.3 Pixel Vectors

A pixel vector is represented by a single digit character in the range of 0 to 7. Each of these numbers refers to one of the eight pixel neighbors relative to the current position. As illustrated in Figure 8-2, pixel vector number 0 refers to the right, pixel vector number 1 refers to the pixel up and to the right, and so forth around a circle in a counter-clockwise direction. These directions are constant, and are not affected by the display surface orientation set by the Screen address setup command S(A[][]). That is, pixel vector 0 is always to the right, even if the +X direction has been defined to be to the left.

The character sequence 2057 refers to a sequence of four pixel vectors and not to the number two thousand fifty seven.

Pixel vectors allow only relative positioning and not absolute positioning.

The default size of a pixel vector is the unit integer size defined by the screen coordinate setup operation, S(A[][]). This length is modifiable by a multiplicative factor specified in the writing attributes instruction. Scaling of horizontal and vertical components of the pixel vector is isotropic, that is, an increment of distance in X is taken to be the same distance as that increment in Y.

Depending on the granularity of the unit pixel size defined by the screen coordinate setup operation, the exact position after executing a sequence of pixel vectors is subject to roundoff error and thus pixel vector positioning sequences should be broken occasionally by absolute positioning, or by position reports.

For the examples which follow, assume that the ReGIS coordinate space has been set with an upper left origin, and that initial values of X and Y are 100 and 50, respectively.

4.5.4 Position Stack

ReGIS provides for the current drawing position to be saved for use by commands which may follow in the command stream. The mechanism for such saving is a stack. A current drawing position can be saved by a "begin block" operation and later, after possibly several intervening position changes, the position can be restored to its old position by an "end block" operation.

The begin and end points are identified by option characters "B" and "E" in the option arguments of the drawing and positioning instructions which use the block structure.

There is only one stack on which positions are saved, and only the Vector and Position instructions have access to this stack. The Curve instruction does NOT use this stack, since the state required for curve maintenance is more complex than that of vectors and positions. Thus, an "end" reference in a vector instruction can cause a position saved by a "begin" operation in a position instruction to be returned.

ReGIS devices must provide a stack at least eight positions deep. While more depth may be provided by devices, conforming software should never assume more than eight entries.

Should stack capacity be exceeded during a save, the current element (the value for which the save failed) is not saved, but discarded.

Stack underflow will cause NO ELEMENT to be returned. NO ELEMENT is distinguished from an empty bracketed pair ([]) in that the former implies no argument present (as would be fetched from an empty macrograph), and the latter implies the use of current position for a position argument. In the case of a null argument to a Vector command, no drawing is done; in the case of an empty argument ([]), a single dot is drawn to indicate a line drawn from the current position to the current position.

5.1.1 Position Arguments

There is no significance to bracketed position arguments to the S command in Base ReGIS.

5.1.2 Numeric Arguments

There is no significance to numeric arguments to the S command in Base ReGIS.

5.1.3 Quoted String Arguments

There is no significance to quoted string arguments to the S command in Base ReGIS.

5.1.4 Options

S(A[0,0][1000,750])

5.2.1 Position Arguments

Position arguments to the position command cause the current drawing position to take on the value specified by the argument.

Multiple position arguments may be associated with a single Position command, or pixel vectors may be intermixed with position arguments. Each argument is executed in turn, providing cumulative results.

5.2.2 Numeric Arguments

Numeric arguments to the Position command are interpreted as single digit pixel vector specifiers. This supports programs which use "chain encoding" techniques and allows small relative changes in the drawing position. A sequence of pixel vector digits may be used, with accumulative results. The number of unit pixels actually moved for each digit is determined by the granularity (the unit distance) of the imposed coordinate space and the current pixel vector multiplier value as set by the writing options instruction.

5.2.3 Quoted String Arguments

There is no defined meaning for quoted text as an argument to the Position command in Base ReGIS.

5.2.4 Options

5.3.1 Position Arguments

There is no assigned meaning for bracketed position arguments to the Write attributes command in Base ReGIS.

5.3.2 Numeric Arguments

There is no assigned meaning for numeric arguments to the Write attributes command in Base ReGIS.

5.3.3 Quoted Text Arguments

There is no assigned meaning for quoted text arguments to the Write attributes command in Base ReGIS.

5.3.4 Options

P111010

5.3.5 Writing Modes

As was noted at the start of this section, the only Writing Attributes required in Base ReGIS are those for the control of line pattern and pixel vector length. Extensions to ReGIS provide for other controls, among them the writing mode, that is, how new drawing actions affect the execution medium. Base ReGIS does not specify what writing mode must be present when these controls are not or cannot be implemented. The two most natural choices are either:

1. Overlay mode, the model that most closely resembles writing with pen on paper, or

2. Replace mode, a model which may be convenient for certain bitmap devices.

Refer to subheadings 8.7.2 Raster Extension and 8.7.2.4.1 Writing Attributes Extensions - Writing Mode Options. for a complete definition of writing modes. The guiding criterion to the device implementor is that visible output is generated.

5.4.1 Arguments

Semantically, the vector instruction is exactly the same as the Position instruction, with the exception that the V instruction can cause a visible image to be generated. The lines drawn by this instruction are subject to the current line drawing pattern selected by the W instruction and the pixel vectors drawn are subject to the current pixel vector multipliers selected by the W instruction.

The B and E options allow the user to define a closed polygon, though this is not the mechanism used in ReGIS to specify a filled polygon. Refer to the section on Position instruction options, and the section on the position stack, for detailed descriptions of the use of the B and E options.

The S option to the Vector instruction is included to provide symmetry with the open Curve instruction. An S option to a vector or position instruction saves a dummy entry on the position stack, consuming one entry of stack space. The matching E option to this S pops the dummy element from the stack without other effect. This dummy element will cause the same action as would be achieved by trying to pop from the empty stack, except that any data below the dummy entry is still valid and available. The dummy entry implies NO ELEMENT, as contrasted with the empty bracket ([]), which implies action at the current position. This allows vector and open curve sequences to use exactly the same argument list to achieve parallel results. Note that the position stack available to the Vector instruction is not available to the Curve instruction. These parallels are parallels of semantics, not of shared or shareable state. Refer to the C(B), C(E) and C(S) sections later in this standard for descriptions of closed and open curve actions.

The W option allows the writing attributes to be temporarily set. After completion of the Vector instruction, the value of the writing attributes returns to those they had before the execution of the V instruction.

5.5.1 Position Arguments

The meaning of a position argument depends upon whether or not a curve position block has been selected.

5.5.2 Numeric Arguments

Numeric arguments to both forms of the Curve command are interpreted as pixel vectors. The pixel vector specifier shall be interpreted as if it were a relative bracketed extent, and executed in the circle or curve context, as appropriate. For instance, C0 = C[+m] where m is the current pixel vector multiplier. If m = 10, then C0 draws the circle just as if it were C[+10]. The pixel vector multiplier should be set to a reasonably large value for these vectors to have worthwhile effect.

5.5.3 Quoted String Arguments

There is no meaning defined for any quoted string arguments to the Circle or Curve command in Base ReGIS.

5.5.4 Options

C(B)[]C[]C[]C[]...

5.6.1 Position Arguments

A position argument to the Text command specifies character escapement, that is, how much the drawing position moves after a character has been drawn. This measure is expressed in units of the imposed coordinate space. It defaults to rightward movement equal to the current width of the character display cell, and no vertical movement. This character to character movement defines what is known as "character path," and describes the orientation of the entire character string. It should not be confused with, nor does it affect, the orientation of the character cell baseline, which is not controllable in Base ReGIS, but is covered in ReGIS extentions. The presence of a bracketed argument to the T command is non-positional. Refer to the subheading 8.4.5.2 Use of Bracketed Extents for Non-Positional Information. This value is always considered relative, regardless of the presence or absence of sign characters on the X and Y parts. Any missing elements are interpreted as +0, that is, no escapement in that dimension. If character size options are supported, they also set character escapement as a side effect.

Character escapement is returned to its default value when a valid S(A) operation is executed.

5.6.2 Numeric Arguments

Numeric arguments to the Text command are interpreted as a form of pixel vector, and cause special motion of the drawing point. This motion is equal to half the current character size. When character height and width are not equal, this movement will take on the proportions of the character cell.

Movement is executed only when the pixel vector digit is encountered, and does not affect, nor is it affected by, the character escapement value. The direction of the 0 pixel vector is parallel to, and in the direction of, the character baseline. (This reference is significant in ReGIS extensions, where the character baseline is not constrained to be parallel to the horizontal axis.) Numbers 1 through 7 step in equal increments, counterclockwise, as for normal pixel vectors. This argument can be used for superscripting and subscripting in text strings.

5.6.3 Quoted String Arguments

Quoted string arguments to the Text command provide the character data to be displayed. Character patterns are retrieved from the stored alphabet (the last alphabet selected by T(A) if multiple alphabets are supported). A0 is the default alphabet, and is the only alphabet required in Base ReGIS. The contents of the A0 may be affected by state set external to ReGIS.

Only within quoted strings used as arguments to the Text command are any control characters interpreted. Only four codes are used: carriage return, line feed, backspace, and horizontal tab:

1. The carriage return code resets the drawing position, both horizontally and vertically, to the value it had at the start of the current quoted text extent.

2. The line feed code moves the drawing position down one character height unit vertically, and saves this new position as that which will be restored should a carriage return code be subsequently encountered in the current quoted extent.

3. The backspace code moves the drawing position back one character escapement step, both horizontally and vertically.

4. The horizontal tab code moves the drawing position forward one character position, just as a space character would, but without drawing anything. The distinction between drawing a space and just moving the drawing position is significant when different drawing modes are considered. A replace mode space executes the background color into the drawing medium, while an overlay mode space or a horizontal tab in any mode do not.

5.6.4 Options

T(A<n>(L"<designating tail>"))

T(A<n>(R"<designating tail>"))

ESC I ... I F

T(A(L"0B",R"1A")).

T(A(L"0J",R"0I"))

T(A(L"(J",R"$+@"))

T(A(R"5A1A"))

5.7.1 Position Arguments

There is no meaning assigned to bracketed position arguments to the Report command in Base ReGIS.

5.7.2 Numeric Arguments

There is no meaning assigned to numeric arguments to the Report command in Base ReGIS.

5.7.3 Quoted String Arguments

There is no meaning assigned to quoted string arguments to the Report command in Base ReGIS.

5.7.4 Options

@=<name><string>@;

R(M(=))

"<free>,<total>"

[x,y]

5.7.5 Further Notes

All reports are terminated by a single carriage return character. Requests for unimplemented reports are acknowledged by the device's returning just a carriage return; this prevents device deadlocks by ensuring that an application will receive some response, even if the requested report cannot be generated.

Multiple options or suboptions to a single R command are interpreted as requests for multiple reports.

All devices must return a report for every option keyletter in the argument stream. Some forms of the report command define a report for every suboption letter as well, as is the case with macrograph reports.

In the case of unimplemented reports, the device may not be able to discern how many reports are due, especially if suboptions are involved (as in the case of the macrograph report). Hence, software should request reports singly and in turn, so that only one report response is outstanding at any time. This will minimize the chance of deadlock or phase error due to unanswered reports.

There are some classes of devices for which reports are not necessary or easily supported. Software to convert ReGIS files to some other graphic form, for example, might not have an identifiable return path for reports. Some devices are meant to be run spooled, and will not have the ability to provide reports in a timely manner, if at all.

Though the ReGIS Report command is part of the ReGIS Base, it clearly cannot be supported in all environments. Lack of support for Reports in such environments does not constitute a failure to conform to the ReGIS standard.

5.8.1 Position Arguments

There is no meaning assigned for bracketed position arguments to the Fill instruction in Base ReGIS.

5.8.2 Numeric Arguments

There is no meaning assigned for numeric arguments to the Fill instruction in Base ReGIS.

5.8.3 Quoted Text Arguments

There is no meaning assigned for quoted text arguments to the Fill instruction in Base ReGIS.

5.8.4 Options

6.2.1 Selection Scheme

To accommodate this broad range of capabilities, the extended ReGIS logical device adopts a scheme to allow the selection of color and gray scale in a simple manner for simple devices, but still has full access to the broad spectrum of attributes of the most capable of the devices.

1. Each pixel has associated with it a foreground and a background "intensity" attribute which are user controllable. The differentiation between foreground and background is most clear in the case of the plotter, and may have little meaning in a multiplane raster color device.

2. For simple color devices, the scale of eight intensity values is interpreted as the three primary colors, the three complementary colors and the black and white intensity values.

   Mappings between gray scale and color should follow the conventions which have been established for photographic and broadcast television work. These are summarized as:

   Gray Scale	Color Value
   0	Black (dark)
   1	Blue
   2	Red
   3	Magenta
   4	Green
   5	Cyan
   6	Yellow
   7	White

   This mapping is based on the standard RGB to luminance level transformation used in the North American television industry (NTSC color standard). The NTSC RGB to luminance equation is

   Y = 0.59*G + 0.30*R + 0.11*B
   

   where Y is the luminance value, and G, R, and B are the green, red, and blue components of the color drive, respectively. When normalized to the range 0 to 7, the equation becomes

   I = 4.1*G + 2.1*R + 0.8*B
   

   where I is the resulting gray scale intensity for that range. The coefficients (rounded to 4, 2, and 1, respectively) lead to the encoding of the table above.

3. For devices having a full range of color capability, the Hue-Lightness-Saturation system of color definition is adopted. In summary, this system requires three possibly floating point numbers to be used in defining a specific intensity parameter value. These are:

   • Hue (H) - the hue of the color expressed as an angle on the color wheel,
   • Lightness (L) - the relative brightness of the color expressed as a percentage of full brightness, and
   • Saturation (S) - expressed as a percentage of the fully saturated hue.

The intensity parameter may be applied independently to the foreground and to the background of the graphic image. Devices have extreme ranges of implementation of the intensity attributes. ReGIS does not define how many colors or intensity levels must be provided by an implementation which offers color or gray scale support.

6.2.2 Color Specification

There are two methods of specifying color or intensity in a graphics device: color by index, and color by value. Color by index is often used in multiplane bit map displays, or in hard-copy devices whose pens are selected by number. Color by value is used by implementations which have limited knowledge of the drawing hardware being used, but which need to specify colors or intensities to differentiate image components. ReGIS supports both color by index and color by value.

I<index>

7.1.1 Position Arguments

There is no significance to the presence of a bracketed position argument in the Screen Instruction Extensions for Raster ReGIS.

7.1.2 Numeric Arguments

There is no significance to the presence of a numeric argument in the Screen Instruction Extensions for Raster ReGIS.

7.1.3 Quoted Text Arguments

There is no significance to the presence of quoted text arguments in the Screen Instruction Extensions for Raster ReGIS.

7.1.4 Options

7.2.1 Position Arguments

There is no significance to the presence of a bracketed position argument in the Writing Attributes Extensions for Raster ReGIS.

7.2.2 Numeric Arguments

There is no significance to the presence of numeric arguments in the Writing Attributes Extensions for Raster ReGIS.

7.2.3 Quoted Strings

There is no significance to the presence of quoted string arguments in the Writing Attributes Extensions for Raster ReGIS.

7.2.4 Options

7.3.1 Position Arguments

Position arguments to the Text command in Raster ReGIS are treated as character escapement values, just as in Base ReGIS.

7.3.2 Numeric Arguments

Numeric arguments are treated as character oriented pixel vector operations in Raster ReGIS, just as in the Base, but differ from the Base in regard to the effect of option extensions. In Raster ReGIS, a character and character string orientation option is present. The direction of the pixel vector operations in Base Raster ReGIS is referenced against this string direction, not against the absolute horizontal. Hence, Text pixel vector direction 0 is parallel to and in the direction of the character baseline, direction 2 is perpendicular the base line (and NOT affected by the italic angle), direction 1 is forward and up, and so on.

7.3.3 Quoted String Arguments

Just as in the Base, the text arguments to be displayed are passed as quoted string arguments, and the four ASCII control codes (carriage return, line feed, horizontal tab, and backspace) are interpreted by ReGIS when encountered within quoted strings.

1. Backspace (BS) moves the drawing position one character escapement increment backwards, both horizontally and vertically.

2. Line feed (LF) moves the drawing position one character height down, perpendicular to the character baseline; LF also saves the resulting drawing position for restoration upon occurrence of a subsequent carriage return in the same quoted extent.

3. Carriage return (CR) moves the drawing position back to the position it had at the start of the current quoted extent, or to that saved at the most recent LF, whichever was more recent.

4. Horizontal tab (HT) moves the drawing position one character increment forward along the baseline.

ReGIS text does not automatically scroll or wrap at screen borders. The drawing point advances by character escapement increments and abides by the addressing constraints outlined in the S(A[][]) Screen Address Setup Command description.

An error character will be displayed for any of the following occurrences:

1. An attempt to print characters from a nonexistent or undefined character set (for example, T(A4)'x', where alphabet 4 has not yet been defined by an appropriate L(A4) command).

2. An attempt to print characters from outside the defined extent of a character set (for example, L(A1,E64) followed by T(A1)'a').

3. An attempt to print not-yet-defined characters from within the defined extent of a character set.

The error character may be device dependent, and need not be the same for each error above. Solid block characters or checkerboard characters are acceptable. The reverse question mark error character used in certain text protocols may not be a good choice, as the rotations and transformations allowed in graphics text may negate the advantages of its otherwise unique shape.

7.3.4 Options

7.3.5 Further Notes

A text "display cell", specified in terms of height and width (using screen addressing coordinates) by T(S[]), is the screen area to be written for each character.

A text "unit cell", specified similarly by T(U[,]), is the screen area in which the image from character storage is drawn. See Figure 8-8. If these two cells are not of identical size, the unit cell is upper-left justified in the display cell, with any display cell area not filled by the character image explicitly filled with the background color. If the unit cell is larger than the display cell, only the upper left portion of the character image is drawn; that is, the unit cell is clipped to fit in the display cell.

In the computational limit (that is, where the granularity of scaling arithmetic is continuous and not bound by pixel increments), the display cell and the unit cell should map to identical sizes. An acceptable fallback for less capable systems restricts Unit cell sizes to integral multiples of the character storage cell defined for the character set by Load Pattern command, L[,]. A unit size that does not represent such an integral multiple may be rounded down to the nearest integral multiple value. Implementations may choose to round up if the target size is only slightly less than the closest realizable size, and if the resulting unit cell would not exceed the display cell. The display cell must be executed to within one physical pixel of its specified size.

The L command defines bit patterns; these are invoked by the T command and as area shading patterns in the W(S'x') command. Alphabet set 0 contains an 8-bit character in-use set. The content of this set is as determined by the ReGIS Base command T(A(L"*",R"*")). All sets except alphabet 0 may be loaded using the L command. See the description of the Load command for further information.

Different alphabets may be simultaneously available for loading and execution.

7.4.1 R(L) - Report selected Loading alphabet

Report back the name of the pattern set currently selected for loading. The format of the report is (A'<name>') where <name> is the name provided in the L(A'<name>') command.

7.5.1 Position Arguments

A bracketed coordinate specifier defines the storage size, in bits per character, to be used with the selected alphabet. This is a non-positional use of bracketed extents. The selected alphabet is cleared when its storage size is specified. The storage size determines how many bits, and how many rows of bits, are encoded into the character mask arguments of the Load command. The storage size maps to the unit cell size when characters are displayed. Negative values are not allowed in storage cell sizes, and the default values for storage cell sizes are device dependent.

7.5.2 Numeric Arguments

Each character cell is redefined by a string of bit patterns expressed as groups of ASCII hex digits (0 ... 9, A ... F or a ... f). A cell is terminated by a semicolon or a successive parenthesized option specifier or quoted character specifier.

Groups of hex digits, each of which specify the contents of one scan line of the character cell, are separated by commas, or by exceeding the maximum number of hex digits needed to specify one scan line. If, in a given device, the default storage size were 12 horizontal by 10 vertical, 3 is the maximum number of hex digits needed to specify one scan line. A fourth consecutive hex digit would be applied to the next scan line whether or not an intervening comma were encountered. Where the default storage size is not known, storage size should be specified, or commas should be used to separate scan line specifiers.

Cells are always loaded one row at a time using hex-ASCII characters. A cell map is specified from the top down, more significant bits leftmost in the specifier string.

1. If more hex digits are specified than are needed for a single line of the mask, the extra digits are used on the next line.

2. However, if the width of the character cell is not a multiple of four, any unneeded, low order bits of the last hex digit applied to that row are discarded, and NOT carried over to the next row. Each raster row is begun with a new digit.

3. If too few digits are specified to fill a row, they fill the low order portion of the mask, setting the high order portion to zero.

4. If fewer mask lines are specified than exist in a cell, the unspecified portion of the cell is cleared to zero.

5. If more lines are specified than will fit in the storage cell, these extra lines are ignored - NOT overflowed into the next sequential character.

Figure 8-9 shows the format of the raster-oriented character storage cell.

7.5.3 Quoted String Arguments

A single quoted character serves as the index into the character set selected for storage. It will be the same character used for recovery of the loaded cell in the Text and Write attributes Shading commands. If more than one character is present in a string, the first is used, and the rest are discarded. Separate character arguments are required to specify multiple mappings.

7.5.4 Options

8.1.1 Position Arguments

In the first data movement model above (the windowing model), position arguments specify an address in the display address space where the origin of the viewing rectangle is to be positioned. Data appear to move left as the origin moves to the right, but since the data and addresses move together, data are generally recoverable by reversing the direction of the movement.

In the second data movement model above (the scrolling model), position arguments specify an address in the display address space which will become the new origin. As in the windowing model, data appear to move to the left as the origin is moved to the right, but in this model the data cannot necessarily be recovered by reversing the scrolling, since the data may have been moved off and erased from the display medium.

If data movement is supported in a ReGIS implementation, the choice of models used is device dependent. If the hardware can support both models, the model in effect is chosen by the S(D) option, described below.

8.1.2 Numeric Arguments

Numeric arguments to the Screen control command are treated as pixel vector specifiers. They are considered to be equivalent to relative address specifiers and are executed as a relative bracketed position argument. The data movement model chosen is the same for pixel vectors as it is for position specifiers.

8.1.3 Quoted String Arguments

There is no significance to quoted string arguments to the S command in Open Extensions to ReGIS.

8.1.4 Options

8.2.1 P(P<n>) - select drawing surface

Some devices have multiple separate drawing surfaces. Programs may select among these separate surfaces with the P option to the P command, P(P<n>). The value of <n> identifies the drawing surface selected. All drawing surfaces share the same state store, that is, current drawing color, selected text alphabet, macrograph store, position stack, and so on.

8.3.1 W(A<n>) - Alternate (blink)

This option enables the blink (or "alternate") attribute. For values of <n> greater than zero, set the blink attribute on all foreground data drawn until blink is disabled. Application of the blink attribute is disabled by W(A0), S(E), or valid S(A). Clearing the subsequent application of the blink attribute by W(A0) does not change the blinking status of any displayed elements, any more than changing the foreground specifier with W(I) changes the color or intensity of any pre-existing data on the display.

The visible action of blink is implementation dependent. The alternation may be between foreground and background intensities, or between foreground and some other device-dependent setting. Interaction of the blink attribute with Complement and other image-content dependent writing modes is device dependent. Blink frequency and duty cycle are device dependent.

8.3.2 W(L<n>) - Line width control

This option controls the width or weight of lines and curves. The value <n> is a multiplier of the device's nominal line width. Nominal line width is device dependent, and is normally the device's default line width. W(L2) sets a width twice the nominal width, W(L3) three times, and so on.

Fractional line widths are allowed. For example, W(L0.5) specifies a width 50% less than nominal, and W(L1.5) specifies a width 50% greater than nominal. Devices that do not support fractions may truncate to the next lower integer or round to the nearest integer, just as they do for other numerics. W(L0) selects the minimum imageable line width.

8.3.3 W(S(<suboptions>)) - Shading

The Shading option to the W command accepts subarguments indicating a shading reference line and shading texture. There are also suboptions to the W(S) form which indicate whether shading takes place to a horizontal line (the default), a vertical line, or to a point. The form W(S(Y)...) indicates that the shading takes place to a horizontal reference line; this is the default. See Figure 7. The form W(S(X)...) indicates that the shading takes place to a vertical reference line. The form W(S(P)...) indicates that the shading is to a point. These suboptions are volatile, that is, every invocation of shading assumes that shading is to a horizontal baseline unless a countering (X) or (P) suboption is provided.

8.3.4 W(W) - microcoded Writing modes

Detailed control of multiplane writing is enabled with the Write control option to the W command, W(W). The option W accepts a numeric index and suboptions P<j> and N<k>. The form of the instruction extension is W(W<i>(P<j> N<k>)). The values <i>, <j>, and <k> are indices for memory contents, typically bit plane values. If a pixel to be written has value <i> before the write operation, it is written to value <j> if the next value from the pattern register, area pattern, or character cell is a 1, or to value <k> if the next masking value is a 0.

These settings override the last specified write mode control option (R, C, V, N, or E), but only those entries explicitly loaded take effect. Any entries not loaded retain their settings as determined by the last effected Writing mode command.

Any Writing mode command overrides all detailed settings.

The default writing modes are reset when a valid S(A) is executed.

8.5.1 R(E) - Report Error

This command reports back the last error encountered by the ReGIS parser. The format of the error report is "n,m", where n is a decimal digit string representing the error code, and m is a decimal digit string returning supplementary information. Except where noted below, this supplementary information is the decimal equivalent of the character code of the character flagged as causing the error. When it cannot be determined exactly what caused the error, 0 is returned in the error character field. Only the most recent error code is kept in the error report register. The error report register is cleared when ReGIS is synchronized by a ";" or by activation synchronization. The error report register is not cleared when the report is sent. The following are the reportable error codes:

• 0 = no_error: No error has occurred since the last synchronizing operation. The supplementary error field returns 0.

• 1 = ignore_character: An unexpected character was encountered and ignored.

• 2 = extra_option_coordinates: A command option that supports paired bracketed extents (such as S(H[][]) or S(A[][])) contained more than two coordinate pairs. The supplementary error field returns 0.

• 3 = extra_coordinate_elements: The syntax [,] contained more than one comma. Characters after the second comma up to the right square bracket (]) were ignored. The supplementary error field returns 0.

• 4 = alphabet_out_of_range: The syntax L(An) or T(An) contained an alphabet number "n" that was less than 0 or more than the implementation limit.

• 5 = alphabet_attribute_error: At least one of the following is true:

  1. In the syntax L(An)[h,w] or L(An,Ex), the alphabet number "n" was zero. The attributes of the default alphabet (alphabet 0) may not be modified.

  2. In the syntax L[h,w], the height "h" exceeded the implementation limit.

  3. In the syntax L[h,w], the width "w" exceeded the implementation limit.

  4. In the syntax L(En), the alphabet extent "n" exceeded the implementation limit.

• 6 = reserved code

• 7 = begin/start_overflow: The implementation limit for position stack depth was exceeded, that is, a V(B), V(S), P(B), or P(S) could not be processed because the stack was full.

• 8 = begin/start_underflow: A V(E) or P(E) was encountered without a matching V(B), V(S), P(B), or P(S) preceding it.

8.5.2 R(I<n>) - Input processing mode

This extension selects between separate or overlapped input and output processing. R(I0) selects "one-shot" mode. In this mode, which is the default mode and is set by executing a valid S(A), processing of ReGIS output is suspended by the device while interactive input (R(P(I)) is pending. Furthermore, input data can be transmitted by the device only once per R(P) or R(P(I)) command.

R(I1) selects "multiple input" mode. In this mode, the device can report positions with or without receipt of R(P) or R(P(I)) commands. The device reports on operator actions on the input devices, typically a mouse or graphics tablet. While in multiple input mode, the device can continue to execute output commands as received.

The commands R(I0) or S(A) exit multiple input mode.

8.5.3 R(P(I)) - Report Position Interactive

This extension differs from the Report Position command in the Base ReGIS in that it enables local interaction with an input device. This command puts the ReGIS device into input mode. In this mode an input device, such as a data tablet, mouse, or cursor keys cause an echoing cursor to be shown on the display surface. This echo tracks the input device, and generates a position report when the user generates a break condition. This break is usually effected by enabling an auxiliary control, such as a control button, associated with the device.

There are three responses allowed to the R(P(I)) command:

1. The normal bracketed coordinate specifier, just as from the normal R(P) command - This is the result from a non-interactive device.

2. An empty report - Only the terminating CR is sent. This is in response to a special break condition set by the user, indicating that NO INPUT was to be returned.

3. A normal bracketed response preceded by a break condition indicator - This indicator may be a single character code or a numeric string. This passes more details of the break condition to the application.

This command is purposely underspecified because of the wide variety of input device and input/output device couplings.

8.6.1 Position Arguments, Numeric Arguments

A position specifier to the F command, either a bracketed coordinate specifier or a pixel vector digit, specifies the location of the "seed" pixel from which a Flood is executed. The border of the flooding operation is as determined by the last previous F(B()) encountered. If more than one specifier is given, each is executed in turn. The current position does not change as the result of any flood operations.

8.6.2 Quoted String Arguments

There is no meaning assigned to the presence of quoted character arguments in Fill or Flood commands.

8.6.3 Options

8.6.4 Further Notes

The Flood command uses as a flood pattern the last selected area shading pattern as defined by W(S<n>), which selects a pattern defined by the linear pattern specifier W(P), or W(S"x"). This is true even if shading has been subsequently disabled by W(S0). Shading should be disabled before a flood or fill operation is initiated. The currently selected write mode and intensity specifier are used. These may be changed by the temporary write options to the Flood command.

The boundary conditions for the flood operation may be expressed in one of three ways:

1. As a specific attribute condition.

2. As any change in attribute with respect to the seed location attribute value.

3. In the single plane system, any change between the foreground and the background state.

The flooded area does not include the boundary. For example, if a red (unfilled) circle is on the display, and the current write mode is solid green, a flood of the interior of the circle will leave a green circle with a red circumference. This allows the edge of other objects to be used as a boundary without modifying that other object.

If the area in which the seed location is found is not closed with respect to the boundary conditions set, the flood will "leak out", causing a writing action that could cover the entire display. Note that non-solid vectors written in overlay mode do not necessarily form closed boundaries.

Areas may have complex boundaries, such as the area between two concentric circles, or the area between bounded figures on a background.

A boundary need only be connected by diagonally adjacent pixels to define closure for Floods.