.de pg
.sp 1
.ne 4
.ti +5
..
.de mh
.sp 4
.ne 10
.ul
.ce
\\$1
.sp
..
.de sh
.sp 2
.ne 10
\\$1
.sp
..
.de hd
'sp 6
.ns
..
.de fo
'bp
..
.de pp
.if \\n%-1 .tl ''-%-''
..
.wh 0 hd
.wh -7 fo
.wh -4 pp
.de ro
.sp
.in -6
\\$1 - 
'in +6
..
.de rr
.sp
.in -6
\\$1
'in +6
..
GPAC is a device independent graphics package
for use under the UNIX operating system, written in the language
C.  GPAC itself is not device independent (although only about
one third of its code is device dependent); it is the user interface
that is independent.  The user selects his device at compile time rather
than execution time for efficiency reasons.  UNIX has no
run time linker and to include all code for all devices into one program
make it too big.  To implement a new device for GPAC, the similar 
routines as in the depgw, deptek, etc. libraries need to be written, and
some variables initialized.  
For some devices many of the routines will not be needed,
so nop routines should be used.
Another way of implementing a device, is
to always use the "null" device currently in GPAC and write a standard format 
sink program
which will translate the standard format produced, and send it to the device
hardware.  This approach is used by the current "cv" device, except the pipe
is set up and the cv scanconverter started automatically in the init call.
This method is quite a bit slower than the direct approach, and the
segmentation features of GPAC are lost to the sink, although they are
still retained for the user.
.pg
GPAC normally runs with I and D space option.  This is essential for the "gw"
device, and the others also do it for consistancy.  In the ginit.c routines 
of the tek, cv and null devices, there is a defined variable ID_SPACE which if
removed will allow running of GPAC not in I and D space.  With this option
user programs also do not declare their display file space: init does
it with an alloc.
.pg
The input routines of the "gw" device are very much dependent on the tablet
driver developed at U of T.  This was because response time was so critical
many functions had to be done in the tablet interrupt routine.
It is feasible that other input devices (e.g., button boxes, mice,
light pens(uhg!!), etc.) could be interfaced in much the
same way.
.pg
Mst of the code is undocumented, but its functions should be
fairly clear.
