In Chapter 2, the main output primitives of GKS have been described without giving any indication of the coordinate system being used to define positions. For example, a polyline joining five points can be defined as:
DO 100 I = I, 5
X(I)=I
Y(I)=0.1*I**2
100 CONTINUE
POLYLINE(5, X, Y)
The polyline could be visualized as shown in Figure 3-1. Here, the coordinate systems on the two axes have been chosen so that the unit length on the two axes is the same. If the unit length was different, a quite different picture of the polyline would have been produced. For example, see Figure 3-2. The user needs to be able to specify the form that the polyline will take on a specific device. He needs the ability to define differential scaling on the two axes if that is appropriate to his problem.
For any problem, the user will have a preferred coordinate system in which he would like to work. The term user coordinates is used for this coordinate system. Most frequently, this coordinate system will be a cartesian coordinate system. However, it is possible that the user coordinate system might be logarithmically scaled or polar coordinates. The only coordinate systems understood by GKS are cartesian coordinate systems. Consequently, if the user coordinate system is not cartesian, the user himself must map his coordinate system onto a cartesian system. On the other hand, if the user coordinate system is cartesian, this can be the coordinate system in which output is described to GKS. To differentiate between the preferred user coordinates and the ones presented to GKS, the term world coordinates (WC) is used to define a coordinate system used to present graphical output to GKS. The difference between the two coordinate systems is illustrated in Figure 3-3.
Let us consider a typical example of graphical output and how it would be dealt with in GKS. The table below indicates some characteristics of New York City temperatures that are to be displayed in a graphical form on some output device.
| Over 100 years | 1965 | |||
|---|---|---|---|---|
| Month | Max | Min | Max | Min |
| Jan | 72 | -6 | 55 | 9 |
| Feb | 75 | -15 | 61 | 13 |
| Mar | 86 | 3 | 61 | 21 |
| Apr | 92 | 12 | 80 | 29 |
| May | 99 | 32 | 94 | 46 |
| Jun | 101 | 44 | 95 | 52 |
| Jul | 106 | 52 | 93 | 58 |
| Aug | 104 | 50 | 91 | 50 |
| Sep | 102 | 39 | 92 | 44 |
| Oct | 94 | 28 | 81 | 32 |
| Nov | 84 | 5 | 71 | 31 |
| Dec | 70 | -13 | 63 | 18 |
We may be interested in displaying the range of temperatures experienced by New York over a 100 year period or how 1965 compares with the extremes of temperature reached in the city during that period. In this example, the user coordinate system and world coordinate system can be made identical if temperature is used as the Y coordinate and the X coordinates go from 1 to 12 indicating the 12 months of the year.
The above data could be input to the computer and stored in four real arrays MAXPR (maximum over the 100 year period), MINPR, MAX65, and MIN65 with the elements 1 to 12 giving the temperature each month. A separate real array MONTH where MONTH(I) is set to I will also be required. To produce a display on some output device, it is necessary to convert the world coordinates by some transformation to the coordinates relevant to the specific device. This requires the following to be done:
Looking at specific devices, the device coordinates vary significantly from one device to another. For example, the Tektronix 4010 storage tube has a screen with coordinates 0 to 1023 in the X direction and 0 to 779 in the Y direction. Other devices have different ranges of device coordinates and some position the origin not at the lower left corner.
To provide a more concrete example of how GKS allows users to define their output in world coordinates and have them transformed to device coordinates, a virtual or normalized device is defined which has a display surface visible in the range 0 to 1 in both the X and Y directions. The coordinates of this device will be called normalized device coordinates (NDC). This is shown in Figure 3-4. To produce visible output, the world coordinates defining the output must be mapped into coordinate positions within the NDC unit square from 0 to 1 in both the X and Y directions.
As mentioned in the previous section, the transformation from world coordinates to NDC must specify the position in NDC space equivalent to a fixed position in the world coordinate space and the extent in the X and Y directions in NDC space of a single unit in world coordinate space.
This enables the user to define the position and extent that his graphical output will occupy on the normalized device. He may wish the output to take up the whole visible area in NDC space. Alternatively, he may wish it to extend over a smal1 part of the complete space.
A convenient method for doing this, and one that has been used extensively in the past, is to define a rectangular area in world coordinate space (called the window) and define where this area will appear on the normalized device (called the viewport). GKS uses this method of specifying how world coordinates are transformed to NDC. This is shown in Figure 3-5. In the world coordinate space, the window is defined by giving the limits of the window in the X direction (XWMIN to XWMAX) and the Y direction (YWMIN to YWMAX). This is transformed into the viewport in NDC space such that the range of X coordinates in NDC space go from XVMIN to XVMAX and the Y coordinates from YVMIN to YVMAX.
The mapping in GKS is defined such that the point (XWMIN,YWMIN) is transformed to the position (XVMIN,YVMIN) and, similarly, (XWMAX,YWMAX) is transformed to (XVMAX,YVMAX). Any position such as (XW,YW) in the world coordinate plane is mapped to a position (XV, YV) in the NDC space in such a way as to preserve its relative position in the rectangle. Thus the ratio of the distance of the point from one of the X boundaries to the length of the X range in world coordinates is equal to the same ratio in NDC. This also applies to the Y axis. Note that both the window and viewport are rectangles, but that there is no constraint that the aspect ratio of the viewport is the same as the aspect ratio of the window. Consequently, a tall thin house (in the diagram) can be mapped into a short fat house on the device.
GKS uses two functions to define a window and viewport as given below:
SET WINDOW(N, XWMIN, XWMAX, YWMIN, YWMAX) SET VIEWPORT(N, XVMIN, XVMAX, YVMIN, YVMAX)
The first parameter N will be ignored for the moment. The other four parameters in each function define the limits of the window and viewport.
Thus, to produce a graph of the New York City maximum temperatures for 1965 which fills the whole of NDC visible space would require window and viewport definitions as follows:
SET WINDOW(N, 0, 12, 0, 100)
SET VIEWPORT(N, 0, 1, 0, 1)
POLYLINE(12, MONTH, MAX65)
This is shown in Figure 3-6. If output is generated before either SET WINDOW or SET VIEWPORT is called, default values for these are used, equal to the unit square. Thus, calling the POLYLINE above before defining the window or viewport is equivalent to:
SET WINDOW (N, 0, 1, 0, 1)
SET VIEWPORT(N, 0, 1, 0, 1)
POLYLINE(12, MONTH, MAX65)
It is good practice not to accept the defaults but define the windows and viewports explicitly, The main purpose of the window and viewport definitions is to define the transformation from world coordinates to NDC. It is possible for several window and viewport combinations to give the same mapping of coordinates from world to NDC For example:
SET WINDOW(N, 0, 12, 0, 100)
SET VIEWPORT(N, 0.25, 0.75, 0.25, 0.75)
gives the same mapping as:
SET WINDOW(N, -6, 18, -50, 150)
SET VIEWPORT(N, 0, 1, 0, 1)
Both define the position (0,0) in world coordinates as being mapped onto the NDC position (0,25,0,25), Both define the scaling in the X direction such that 1 unit in world coordinates is equivalent to 1/24 of a unit in NDC space, The scaling in the Y direction in both cases is such that 1 unit in the world coordinate space is equivalent to 1/200 in the NDC space, Later, we shall see that the viewport boundary is used for other purposes as well. Consequently, a specific viewport may have to be used in some cases.
The transformation of coordinates from world coordinates to NDC defined by the window to viewport mapping is often called the normalization transformation in GKS.
Frequently, the user of GKS will wish to generate quite complex graphical images in the NDC space and the image may have different appropriate world coordinates for different parts of the picture. For example, to annotate the graph defined in the previous section, units such as the temperature in New York City are inappropriate for defining the height of the characters in the text.
To solve this problem, there are two distinct approaches. The first solution would be to have a single normalization transformation which could be redefined before each part of the picture is output. There are some disadvantages to this approach which become more important when locator input and interaction are used. The second solution, and the one adopted in GKS, is to allow the user to define a number of window to viewport mappings. In the previous section, the parameter N in the definitions of the functions SET WINDOW and SET VIEWPORT is used to differentiate between the different normalization transformations. Values of N range from 0 (which has a special significance and will be described later) to some installation defined maximum which will be of the order of 20 or more. Thus:
SET WINDOW(N, XWMIN, XWMAX, XYMIN, XYMAX)
defines the Nth window and similarly for SET VIEWPORT.
It is good programming practice to define the windows and viewports used in a particular application at the head of the program. They can be thought of as a declaration defining the overall structure of the output.
To define which window to viewport mapping is to be used with a particular output primitive, a function is provided which selects a particular transformation as being in force until another is selected. The function:
SELECT NORMALIZATION TRANSFORMATION(N)
specifies that normalization transformation N should be selected. The default transformation is number 0. Consequently, the examples in the previous section were not strictly accurate and should have been:
SET WINDOW(N, 0, 12, 0, 100)
SET VIEWPORT(N, 0, 1, 0, 1)
SELECT NORMALIZATION TRANSFORMATION(N)
POLYLINE(l2, MONTH, MAX65)
An example showing how multiple normalization transformations might be used is given below. The aim is to produce four graphs with axes giving the maximum and minimum temperatures over the 100 year period and for the year 1965. We make use of a subroutine AXES which was defined in Section 2.3. It outputs axes from the origin to maximum values in the X and Y directions, Producing the four graphs requires:
SETWINDOW(1, 0, 12, -15, 110)
SET VIEWPORT(1, 0.1, 0.4, 0.6, 0.9)
SETWINDOW(2, 0, 12, -15, 110)
SET VIEWPORT(2, 0.6, 0.9, 0.6, 0.9)
SET WINDOW(3, 0, 12, -15, 110)
SET ViEWPORT(3, 0.1, 0.4, 0.1, 0.4)
SET WINDOW(4, 0, 12, -15, 110)
SET VIEWPORT(4, 0.6, 0.9, 0.1, 0.4)
DO 100 I = l, 4
SELECT NORMALIZATION TRANSFORMATION(I)
AXES(l2, 110)
100 CONTINUE
SELECT NORMALIZATION TRANSFORMATION(1)
POLYLINE(12, MONTH, MAX65)
SELECT NORMALIZATION TRANSFORMATION(2)
POLYLINE(12, MONTH, MIN65)
SELECT NORMALIZATION TRANSFORMATION(3)
POLYLINE(12, MONTH, MAXPR)
SELECT NORMALIZATION TRANSFORMATION(4)
POLYLINE(12, MONTH, MINPR)
The output is given in Figure 3-7.
As another example of how to use several window to viewport transformations to compose a picture, consider the problem of annotating the graph of maximum New York temperatures. As stated before, a coordinate system with temperature in one direction and months of the year in the other is not the most ideal for defining the size and position of textual annotations to the graph.
The graphical output falls into three distinct classes:
and these three windows need to be mapped onto viewports as shown in Figure 3-8. A possible set of window to viewport mappings would be:
SET WINDOW(1, 0, 12, 0, 120)
SET VIEWPORT(1, 0.2, 0.8, 0.15, 0.75)
SET WINDOW(2, 0, 4, 0, 16)
SET VIEWPORT(2, 0.0, 0.2, 0.15, 0.95)
SET WINDOW(3, 0, 15, 0, 3)
SET VIEWPORT(3, 0.2, 0.95, 0.0, 0.15)
Note that the second and third normalization transformations preserve the aspect ratio. Space has also been left to allow the Y axis text to extend above the height of the graph and the X axis text to extend past the right hand end of the graph. The graph can be drawn as before by:
SELECT NORMALIZATION TRANSFORMATION(1)
AXES(12, 120)
POLYLINE(12, MONTH, MAXPR)
To draw the text on the Y axis would require:
SELECT NORMALIZATION TRANSFORMATION(2)
DO 100 I = I, 12
X(I)=4
Y(I)=I
100 CONTINUE
SET POLYMARKER INDEX(3)
POLYMARKER( 12, X, Y)
SET CHARACTER HEIGHT(0.5)
SET CHARACTER UP VECTOR(-1, 0)
TEXT(1.5, 2.5, 'MAX NEW YORK TEMP')
SET CHARACTER UP VECTOR(0, 1)
DO 200 I = 1, 12
CONVTX(I*10, STRING)
TEXT(2, I, STRING)
200 CONTINUE
The first part of the output generates tick marks on the axes using the plus sign marker. The second part defines the main annotation on the Y axis while the last part defines the temperature values. The subroutine CONVTX converts the integer number given into its character form.
The text on the X axis could be produced in a similar way:
SELECT NORMALIZATION TRANSFORMATION(3)
DO 300 I = 1,12
X(I)=I
Y(I)=3
300 CONTINUE
POLYMARKER(12, X, Y)
SET CHARACTER HEIGHT(0.25)
SET CHARACTER UP VECTOR(0, 1)
SET TEXT INDEX(N)
TEXT(0.625, 2, 'JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC')
where text representation N is assumed to be a font with the width of each character being the same (i.e. mono spaced) and equal to the height. The output would be as shown in Figure 3-9.
A problem that comes to light if we attempt to generate a graph of the minimum temperature rather than the maximum can be seen if we substitute:
POLYLINE(12, MONTH, MINPR)
for the call to POLYLINE in the above example. Does this give the output shown in Figure 3-10? Because the Y coordinates of the minimum temperature go negative, the polyline is drawn outside the boundary of the viewport defined by the first normalization transformation. If the complete polyline is drawn, the effect is as in Figure 3-10. The graph overwrites the titling causing a rather poor representation.
GKS, in fact, allows two possibilities if the user attempts to draw outside the boundary of the viewport. In one mode, drawing is allowed as shown in Figure 3-10 and, in the other, drawing is clipped at the boundary of the viewport, so that only those parts of the polyline primitive inside the viewport are actually drawn. Both possibilities have their uses and it is up to the user to define which he requires. In fact, the default in GKS is to clip the output to the viewport boundary so that the output shown above would not have been generated. In GKS, it is possible to choose whether or not to clip to the viewport boundary by calling the function:
SET CLIPPING INDICATOR(IND)
where IND can take the values CLIP and NOCLIP as appropriate. Thus the graph in Figure 3-10 would be produced by:
SELECT NORMALIZATION TRANSFORMATION(1)
SET CLIPPING INDICATOR(NOCLIP)
AXES(12,120)
POLYLINE(12, MONTH, MINPR)
To produce the clipped output shown in Figure 3-11, the program would be:
SELECT NORMALIZATION TRANSFORMATION(1)
SET CLIPPING INDICATOR(CLIP)
AXES(12,120)
POLYLINE(12, MONTH, MINPR)
Alternatively, if the clipping indicator has not been reset previously, it will retain the original default value of CLIP so that the call to SET CLIPPING INDICATOR can be omitted.
Note that the clipping indicator is associated with the currently selected normalization transformation. There is not a separate clipping switch for each normalization transformation.
If the clipping indicator is set to CLIP, polylines will always be clipped at the boundary of the viewport. However, the situation as far as other output primitives is concerned is not always as straightforward. In the case of polymarkers, the individual markers will only be output if the centre of the marker is within the viewport. This does mean that a marker which is just inside the viewport may have some part of its form outside the boundary if the centre is within. The clipping of TEXT depends on the precision of the text being output. The lowest (STRING) precision text may be completely removed if the position of the start of the text is outside the viewport. For CHAR precision text, clipping is done on a per character basis with the character only being output if the complete character box is within the viewport. For STROKE precision text, clipping is performed at the boundary of the viewport. The difference between CHAR and STROKE clipping is shown in Figure 3-12; the dashed lines indicate those parts that would be removed by clipping.
In general, normalization transformations can be redefined at any time by either redefining the window or viewport. It is usual to define all the normalization transformations required in a picture prior to outputting it. However, although this is regarded as good practice, it is not mandatory. In some circumstances, it may even be necessary to redefine the normalization transformation during the output.
Normalization transformation 0 is rather special in that it cannot be redefined ever. Its value is equivalent to:
SET WINDOW(0, 0, 1, 0, 1)
SET VIEWPORT(0, 0, 1, 0, 1)
An attempt to change it will cause an error. It provides a mechanism so that a user can define his output directly in NDC rather than using world coordinates. Occasions may arise when this is preferable.