A GKS metafile is produced by a standard GKS output-only workstation. The workstation must first be 'opened' (GOPWK), then 'activated' (GACWK), and all graphical information following these calls is recorded on the metafile as a series of items (listed in an appendix of the GKS/GKS-3D Primer) until a 'deactivate workstation' is encountered (GDAWK). Hence the application must control it in the same way as a terminal or a plotter. Clearly, some of the workstation inquiry functions, such as Inquire Text Extent, can not be used because this knowledge depends on the device(s) ultimately chosen to interpret the metafile. Thus, a GKS metafile does not record a complete 'picture' so much as all the actions performed to make such a picture. If the application deletes segments and then draws different ones, all this will be recorded on the metafile if it is active.
This last point has a number of ramifications. Because the metafile captures all the output generated whilst it is active, it could be used to record a dynamic sequence, like a cartoon, as long as it is re-interpreted onto a dynamic display system. However, if the object of the exercise is to interpret the metafile onto a hardcopy device, it is not clear what the interpreter would be expected to do with, for example, a Delete Segment operation! Thus, for this kind of use, the metafile workstation should only be activated when a finished picture is ready to be output, perhaps by copying the image from WISS. A classic mistake is to leave the metafile workstation activated whilst one works interactively on a terminal, and then crash when all the available disc space is used up.
To open an Appendix E metafile workstation the call is:
CALL GOPWK(WKID, CONID, WTYPE)where the parameter WTYPE specifies the metafile workstation which is defined in the documentation for the GKS implementation in use (see Appendix on Page
for the GKSGRAL values).
The metafile will be written to the logical unit number corresponding
to the connection identifier (conid) in the GOPWK call
(see section on Page for legal values).
On VM/CMS, a conid of XX with no OPEN or FILEDEF statements would result
in a metafile name 'FILE FTXXF001'.
A convenient way to declare FILEDEFs from a FORTRAN program is to use
the CERN library routine VMCMS (code Z305).
However, Version 2.3 of the VM/CMS FORTRAN compiler provides the
possibility to specify the file name in the OPEN statement,
and this is now the recommended mechanism. A '/' is required
before the filename:
OPEN(UNIT=CONID, FILE='/filename filetype filemode', STATUS='NEW')
On VAX/VMS the metafile can be written to a file which should be opened prior to the call to GOPWK. If there is no OPEN statement, the metafile will be written to FOR0XX.DAT, where XX is the specified conid, unless FOR0XX is defined as a logical name. Under VMS, the OPEN statement should read:
OPEN(UNIT=CONID, FILE='filename.ext', STATUS='NEW')
On APOLLO the OPEN statement is mandatory with a format as above.
On the CRAY the OPEN statement is optional. If it is missing, then
the file will be given the name 'fort.N' where N is a number from 1 to
99 corresponding to the connection id. Note that unlike on VMS,
a value of N from 1 to 9 has no leading 0.
If a file name has not been defined via the open statement, then one can
be assigned using the command 'assign -a myname fort.N'.