Editing Graphics development with vplot (section)

==Program structure==
The philosophy behind vplot and pen has been to have users' programs write
output in a device-independent language, and to present the results in a
compatible manner on all devices. All the filters share a common
user/operating system interface routine, called frontend, and a common
vplot command interpreter, dovplot.c. Frontend consists of 3 parts:
main_vplot, init_vplot, and proc_vplot. The routines in utillib.a
are mostly low-level and device independent. Genlib.a is a set of generic
routines which is capable of providing all or almost all of the functions
needed to support a GKS vector output package. The programmer is free
to use these routines in a device driver, or to substitute calls to
high-level hardware capabilities. Loclib.a contains a subset of the 
seplib library, including routines for writing/reading vplot and for
receiving parameters from the command line and initialization
files.

The heart of the device support system is the file <dev>conf.c
where <dev> is the name of the device. Inspired by the file
/usr/sys/machine/conf.c which configures the UNIX operating system
to accept peripheral devices, this file is composed of three parts:

<ol><li>
Declaration of the variables necessary to do self-documentation:
<syntaxhighlight lang="c">
char name[] = "Filter name";
char *documentation[] = {...documentation...};
int doclength = {sizeof documentation / sizeof documentation[0] };
</syntaxhighlight>
You may wish to include "gendoc.h" as part of your documentation string.
</li><li>
Declaration of the routines which have been chosen/written to provide the various functions. All the routines named in part 3 must be declared, as well as all the routines which they may call.
</li><li>
Initialization of a structure of pointers to the routines which do the work. Since this structure is read directly by dovplot.c, it is vital that the all entries be filled in order. Each subroutine name can be one of three types:
<ol style="list-style-type:lower-alpha"><li>
A device-specific subroutine name such as "envipoint". (Note the first 4 characters of the name are a unique identifier for the device, and the rest of the name tells which routine in the table this is. The 4 letter identifier is usually tacked onto "pen" to give the pen filter name (such as "envipen") and onto "lib" to give the subdirectory name (such as "envilib").)
</li><li>
A generic subroutine name such as "genpoint". Generic subroutines simplify the device's work by handling things in software. They in turn call other, simpler, device routines. Generic routines are useful because by using them it is very easy to rapidly support all the primitives on a device. If the device can do things in hardware, however, it is usually preferable to write a device-specific routine to use that capability since that is much more efficient.
</li><li>
The do-nothing subroutine "nulldev". Nulldev is an all-purpose generic subroutine that simply returns. It can either be used as a place holder for routines your device doesn't use, or it can be used in cases where there is simply no reasonable way to handle that particular primitive on that device.
</li></ol></li></ol>
The usual procedure for creating a new driver has been to steal as
much code as possible from a driver for a similar device,
or from the generic library. For a Tektronix emulator, this can be as
simple as checking that the mode changes are handled properly by dev.open
and dev.close, and writing a devconf.c with the proper subroutine names.
For a start, it should be possible to get a less-standard device going
with devopen, devclose, and devplot routines, relying on generic routines
for all other functions. Figure 1 contains the device structure for the
Envision 220.
<syntaxhighlight lang="c">
struct device   dev =
{
 /* control routines */
    enviopen,		/* open */
    envireset,		/* reset */
    envimessage,	/* message */
    envierase,		/* erase */
    enviclose,		/* close */

 /* high level output */
    genvector,		/* vector */
    genmarker,		/* marker */
    gentext,		/* text */
    genarea,		/* area */
    genraster1,		/* raster */
    envipoint,		/* point */
    enviattributes,	/* attributes */

 /* input */
    envigetpoint,	/* getpoint */
    geninteract,	/* interact */

 /* low level output */
    enviplot,		/* plot */
    envistartpoly,	/* startpoly */
    envimidpoly,	/* midpoly */
    enviendpoly		/* endpoly */
};

/* Figure 1: device structure for envipen */
</syntaxhighlight>