Chapter 2 described in detail the major output primitives of GKS that may be familiar to users of other graphics systems. This chapter describes the more specialized output primitives. Cell array allows images to be output. Generalized drawing primitive allows special hardware drawing capabilities to be used. This chapter also describes the escape function, which allows special hardware to be used, but does not contain coordinate information.
For colour raster displays, there is often a need to specify images containing a variety of colours or grey levels which specify a picture. Effectively, the user wishes to associate a particular colour or grey scale with each pixel of the raster display. For sophisticated raster displays, this will normally be done by associating a number with the pixel which identifies a position in the colour look-up table associated with the frame buffer of the display.
In GKS, the primitive used to specify images of this type is called cell array. It differs from the pixel image described above in a number of ways. The major one is that the individual cells are rectangular areas in world coordinates and may map on to one or more pixels in the coordinate space of a particular device. It can be thought of as a virtual pixel array. The cell array function is specified by:
CELL ARRAY(XL, YL, XR, YR, DIMX, DIMY, SX, SY, DX, DY, CA)
The two points in world coordinates (XL,YL) and (XR,YR) specify the opposite corners of a rectangular area which is to be divided into DX cells in the X direction and DY cells in the Y direction. Associated with each cell is a colour specified by the entry in the array CA(I,J) where I takes values from SX to (SX+DX-1) and J takes values from SY to (SY+DY-1). The corner cell at (XL,YL) corresponds to the array element CA(SX,SY) and the one at (XR,YR) corresponds to CA(SX+DX-1 ,SY+DY-1). The entry CA(I,J) contains the position in the workstation colour table where the RGB values of the colour are specified (see Figure 12-1 ).
Note that the area of the pixel array and the colour numbers associated with the cells are specified in the virtual side of GKS. The colour look-up table on the other hand is specific to a particular workstation. Thus, it is quite easy to specify a cell array which can be viewed quite differently on two different workstations. One could, for example, have a colour table specifying the picture as a grey scale image while a second specifies it as a pseudo colour one.
As the cell array is specified in world coordinates, it is subject to all the transformations that can be applied to other primitives. In particular, segment transformations and differential scaling in the transformation from world coordinates to normalized device coordinates allow the cell array's border to deform to a parallelogram and possibly get clipped by the window boundary. When this is mapped on to the pixels of a raster display, the pixel takes the colour specified by the cell in which the pixel's centre is contained.
Normally, cell arrays will be used to map images directly on to pixels. By carefully mapping the world coordinate window so that it maps precisely on to the complete viewport of the display, it is possible to ensure that a raster image is mapped 1:1 on to the pixels of the display. For example, suppose an image is specified by IMAGE(512,512) where IMAGE(I,J) is the colour table entry for the required colour. To map this on to a 512 × 512 raster workstation (RW) would require:
SET WINDOW(1, 0, 10, 0, 10)
SET VIEWPORT(1, 0, 1, 0, 1)
SELECT NORMALIZATION TRANSFORMATION(1)
OPEN WORKSTAT10N(RW, 3, 8)
SET WORKSTATION WINDOW(RW, 0, 1,0, 1)
SET WORKSTATION VIEWPORT(RW, 0, 512, 0, 512)
ACTIVATE WORKSTATION(RW)
CELL ARRAY(0, 0, 10, 10, 512, 512, 1, 1, 512, 512, IMAGE)
The workstation type is specified as 8, which in Section 7.2 indicated a raster display of resolution 512 × 512 at the installation described there.
It may happen that the user wants to check the cell array output on a device other than a raster display. In this case, the implementation is not forced to produce a complete pixel image. Instead, it can approximate the cell array as best it can. In the very worst case, it is allowed just to draw the boundary of the cell array. On a plotter, a reasonable representation might be to draw a point of the nearest colour to the one required at the centre of each cell of the cell array.
The inquiry function INQUIRE DISPLAY SPACE SIZE described in Section 8.4.1 can be used to map a cell array precisely onto a raster display of any size greater than 512 by 512. The UNITS parameter will either return a value METRES or OTHER. In the first case, the display area is defined by RX and RY in metres. However, IX and IY give the addressable positions on the display in each direction. If IX and IY are greater than 512, to map the cell array onto the lower left corner covering 512 raster positions in each direction requires:
SET WORKSTATION WINDOW(RW, 0, 1, 0, 1)
SET WORKSTATION VIEWPORT(RW, 0, RX*512/IX, 0, RY*512/IY)
If the UNITS parameter returns a value of OTHER, it is likely on a raster display that the installation has defined the device coordinates as in the example given above.
There exist on the market displays which have hardware capabilities to draw circles, ellipses, arcs and even spline curves. As the most complex line drawing primitive is the polyline, it would be difficult for such hardware to be used in GKS unless there was some mechanism provided in GKS to allow the full capabilities of each workstation to be exploited. The output primitive provided in GKS for this purpose is the Generalized Drawing Primitive or GDP for short.
The GDP function takes the form:
GENERALIZED DRAWING PRIMITIVE(N, PX, PY, ID, LDR, DR)
The parameter ID specifies the type of GDP to be output. The two arrays PX and PY of length N specify a set of positions in world coordinates that will be used in the definition of the GDP. As the GDP can have considerably different parameters depending on its type, an array DR of LDR elements is provided to give additional non-coordinate information. This is the GDP data record. Section 9.3.4 describes how data records can be constructed. The precise contents of the data record for each type of GDP will be described in the local installation handbook. It is quite possible for a workstation not to support any GDP types at all, as they are not standardized; a program using a GDP might work on one workstation but not on another. Positive GDP numbers are the subject of registration. Registering a GDP will have the effect of adding an output capability to GKS, but even so a workstation does not have to support it. Negative GDP numbers are defined by the local GKS installation.
However a GDP is defined, certain properties are guaranteed by GKS. The major point is that the GDP specifies a shape or curve in world coordinates and this must appear as the correctly transformed shape on the device, For example, a GDP specifying a circle might be transformed by the normalization transformation into an ellipse. In this case, the workstation is expected to display it correctly.
A possible GDP might be one where N is set to 3 and the three points specify a circular arc whose centre is the first point and the last two points specify the start and end points of the arc. The parameter LOR could be set to indicate a single data value OR( I) which specifies whether the arc is to be drawn clockwise or anticlockwise.
As a GDP could be similar to anyone of the other output primitives. it is allowed to use the most appropriate primitive attributes, possibly from more than one primitive. For example, the arc specified above would probably use the polyline index value to specify the type of line to be used.
The exact form of the GDPs on a particular site should be looked up in the local installation handbook. It is possible that the GDP will only be implemented on a subset of workstations with the others returning a minimal interpretation.
The ESCAPE function provides another way of specifying non-standard activities in GKS. Although GDP specifies non-standard output primitives, it is constrained to deal with geometric output and it is expected to do the correct conversion from world to device coordinates.
The ESCAPE function, on the other hand, gives an installation the ability to control facilities on a device which would be impossible by the standard GKS functions. It also allows information on non-standard quantities to be read back to the application program. The only constraints on the ESCAPE function are that it should not violate the general design concept of GKS, does not change the state of GKS and does not produce geometric output. An example might be the output of voice or sound annotations to some graphical output (or simply sounding the bell). The form of the GKS function is:
ESCAPE(FCTID, INL, INDR, OUTDIM, OUTL, OUTDR)
The first parameter specifies the type of escape function. The array INDR is the ESCAPE input data record (of dimension INL), which is input from the application program to ESCAPE. The array OUTDR is the ESCAPE output data record (of dimension OUTDIM) which is output to the application program by ESCAPE; OUTL is the number of array elements actually used. Section 9.3.4 describes a function that can be used to construct data records. The precise contents of the data record for each type of escape function will be described in the local installation handbook.