.ps 60,76
.flags bold
.title PIC
.c 76;PIC -- A Language for Typesetting Graphics
.b 2
.c 76;Sohail Aslam
.b 2
.c 76;UCCS Computer Science Department
.b 2
.c 76;^&ABSTRACT\&
.b 1
.sp 1
.p 5,1,4
For those who are familiar with UNIX, PIC is new UNIX tool for
typesetting graphics in 
documents produced using TROFF (NROFF). The approach is so elegant that I 
decided to implement PIC on the VAX to generate pictures on commonly 
available graphics devices. PIC is described by Brian Kernighan in 
"PIC#-#A Language for Typesetting Graphics", Software#-#Practice and
Experience, Vol. 12, 1-21 (1982).
.p 5,1,4
PIC is a language for specifying pictures so that they can be typset as an 
integral part of a document. The basic objects in PIC are boxes, lines, 
arrows, circles, ellipsed, arcs and splines, which may be placed at 
positions specified absolutely or in terms of previous objects and labelled 
with arbitrary text. Most of the effort in designing PIC has gone into 
making it possible to specify the sizes and positions of objects with minmal 
use of absolute coordinates. This document describes PIC, with primary 
emphasis on those aspect of the language that make it easy to use. The example 
below illustrates the general capabilities of the language.
.figure 10
This picture was created with the input
.nj.nf.b 1
.ta 5 14
	ellipse 'document'
	arrow
	box 'PIC'
	arrow
	box 'TBL/EQN' '(optional)' dashed
	arrow
	box 'TROFF'
	arrow
	ellipse 'typesetter'
.j.f.b 1
.pg
.hl 1 DESIGN CONSIDERATIONS
.p 5,1,4
It is all too common that figure presentation is essentially independent
of the rest of preparing a document:  figures are sketched, drafted (often 
several times until they are "right"), then glued onto the final manuscript. 
Any change requires a substantial effort.  In fact, the whole process is so
laborious that authors shy away from using figures merely because of the 
difficulty of producing them.  The purpose of PIC is to eliminate this 
painful manual effort.
.p 5,1,4
It was also decided very early that users would create pictures by typing 
ordinary ASCII text at a standard terminal, not by sketching them on a 
graphics device as is done in a system like DRAW.   This decision was in 
part forced by the fact that there are very few decent graphics input 
devices available (at least to me), while terminals are ubiquitous.  
.p 5,1,4
The remaining goals, insofar as they were ever articulated, were normal ones 
of having a language that is easy to learn and use.  This translates into a 
handful of more specific considerations.
.p 5,1,4
First, many graphics languages lean heavily on the use of absolute Cartesian 
coordinates for specifying the positions and sizes of objects:  each point 
is positioned in terms of its x and y coordinates in the plane.  
Absolute coordinates are sufficient, in that 
anything can be expressed in such terms, but they make it hard both to 
create the first draft of a picture and to modify it subsequently.  Absolute 
coordiantes also discard any structural relationships that might exist among 
the objects in a picture.  PIC tries to provide alternate methods, so that a 
typical picture requires few, in any, absolute coordinates.
.p 5,1,4
Second, PIC tries to arrange sensible defaults for everything in sight, so 
that simple pictures can be made with a minimal amount of specification.  
Object sizes, text positions, and the relations among objects all have 
default values intended to be what most people want.
.p 5,1,4
Third, the intended user population for PIC includes not only technical 
authors, but 
secretaries and typists, who have as little patience with complex language 
syntax as they have for doing arithmetic on graph paper.  Therefore the PIC 
language tries to give the illusion of being "English-like," with 
straightforward (though prolix) syntax and little punctuation.  
.hl 1 THE PIC LANGUAGE
.p 5,1,4
PIC provides as primitives boxes, lines, arrows, motions, circles, ellipses, 
arcs and cubic B-splines plus 
facilities for positioning and labeling them.  A picture is written as a 
sequence of statements, one per line, or seperated by semicolons.  Each 
statement requests a primitive, perhaps qualified by a set of attributes such 
as position, text, height, width, etc., which may appear in any order.
.p 5,1,10
The picture specification is introduced by a line beginning with "origin"
.nj.nf.b 1
	origin = ( x,y )
.j.f.b 1
which specifies where the first primitive is to be located. 
Thus, as a simple example,
.nj.nf.b 1
	origin = ( 4,7.5 )
	box 'this is' 'a box'
.j.f.b 1
produces the archetypal box:
.figure 4
.p 5,1,4
A primitive may be followed by any number of quoted text strings;  these 
will be printed in the current size and font, centered vertically and 
horizontally at the center of the object.  (Text position, size and font can 
be controlled more precisely if needed, but this default is right for the 
majority of situations.)   Technically, text strings are attributes in 
exactly the same way that height and width are. One enters a _' by typing two 
_'_' as in 
.nj.nf.b 1
	box 'it''s a nice' 'day' 
.j.f
.p 5,1,4
The contents of the strings are examined by PIC for color or
font control information to be passed on to graphics device drivers (more on
device drivers later)
thus it is easy to get fonts such as Old English:
.nj.nf.b 1
	ellipse  '_\f(oeHave a ' 'nice day'        
.figure 5
.j.f.b 1
The "_\f(oe" is a directive to change the font. Colors can be changed by using 
the "_\c(" directive. Here is old english in red.
.nj.nf.b 1
	ellipse  '_\f(oe_\c(rdHave a ' 'nice day'        
.figure 5
.j.f.b 1
Note that some graphics devices are not capable of producing color of font 
changes. On a DEC VT125 for example, one would have to live with "American" 
instead of "Old English".
.p 5,1,4
The proper mental model for writing a PIC picture is to imagine oneself 
walking around on a plane dropping primitives.
The plane has a Cartesian coordinate system with dimensions most easily 
expressed simply in inches, so the last-resort mode of operation is to 
specify absolute size and position for each object explicitly, as in
.nj.nf.b 1
    	box ht 0.3 width 0.5 at (0.25,0.15)
	arrow from (0.25,0.15) to (0.75,0.15)
.j.f.b 1
The pair (0.25,0.15) represents an x,y coordinate measured in inches. The 
parenthesis are necessary.
.p 5,1,4
As suggested above, absolute coordinates and dimensions are not at all 
convenient or flexible, so PIC goes to some effort to help users get by 
without them.  The major tactics for avoiding such specifications are 
default dimensions, automatic positioning, and naming conventions for 
positions.
.p 5,1,4
Primitives have default dimensions chosen so that instances of them fit 
together without too much efort.  For example, the standard box is 1/2"
by 3/4", as is the ellipse; the circle and arc have a 1/2" radius, and the 
standard line and motion are 1/2".
.p 5,1,4
The attributes "up", "down", "left", "right" "upright" etc., can be 
applied to the primitives
"line" or "arrow" to specify a direction, a distance, or both.  For example,
.nj.nf.b 1
	line upright
.j.f.b 1
draws a line upwards and to the right:
.figure 5
The distance is defaulted here, but could be given explicitly, as in
"line upright 0.5."
.p 5,1,4
Default dimensions are controlled by variables that may be set at any time 
to any value by assignment statements like
.nj.nf.b 1
	boxht = 0.3; boxwid = 2 _* boxht
.j.f
.p 5,1,4
Objects are connected by default in the direction of motion, e.g., left to 
right, so the input
.nj.nf.b 1
	arrow;  box;  arrow;  circle;  arrow
.j.f.b 1
produces
.pg
The direction of motion can be changed by the explicit commands "up", "down", 
"left", "right", "downleft", etc,
so merely prefixing the command "up" to the line above 
.nj.nf.b 1
	up; arrow;  box;  arrow;  circle;  arrow
.j.f.b 1
will produce
.figure 16
The direction of motion also changes automatically when a line or arrow or 
arc implies a change, as in
.nj.nf.b 1
	line;  arc;  arc cw;  arrow
.j.f.b 1
.figure 6
The atttribute "cw" means clockwise;  default arcs are counter-clockwise.
.p 5,1,4
Pictures do not always grow left to right so neatly, so PIC provides several 
ways to refer to parts of a picture drawn perviously.
.p 5,1,4
First, any object can be labeled, as in
.nj.nf.b 1
	Start:  box ...
.j.f.b 1
This associates the name "Start" with this box; subsequent commands may refer 
to "Start", as in
.nj.nf.b 1
	move to Start
.j.f.b 1
The label "Start" actually refers to the center of the object.  To permit 
access to a side or corner without using the coordinates of the center and 
arithmetic on the dimensions, PIC provides "corners", that is, standard 
named points on each object.   Most objects have the eight compass point 
corners ("north", "ne", etc.) "top" and "bottom" as synonyms 
for "north", etc., and "start", "end" and "center".  Thus one can say
.nj.nf.b 1
	B1:	box
		arrow;  box;  arrow
	B3:	box
		arc -_> from top of B3 to top of B1
.j.f.b 1
to get
.figure 8
-_> asks for an arrowhead.  If the radius of an arc is not specified, a 
"large enough" radius will be supplied.
.p 5,1,4
Long phrases like "top of B3" can be abbreviated to "B3.top".
Expressions involving corners are also legal, as in
.nj.nf.b 1
	top of B + (0.5,0.1)
.j.f
.p 5,1,4
Since it is clumsy to have to invent labels for things, objects may be 
referred to by their ordinal position in the input.  The example above can 
be written instead as
.nj.nf.b 1
 	box;  arrow;  box;  arrow;  box
	arc -_> from top of last box to top of first box
.j.f.b 1
All kinds of combinations like "first", "second", "third last", and so 
on are recognized.
.p 5,1,4
The "last" object of a given type is of course the most recent, as 
illustrated here:
.figure 6
.nj.nf.b 1
	arrow
	box ht 0.3 wid 0.3 'x'
	box same
	arrow from center of last box
	box same 'y'
	box same
	arrow from center of last box
	box same 'z'
	box same
	line from last box.sw to last box.ne
.j.f.b 1
The attribute "same" causes the dimensions of the previous box to be used 
instead of the default.
.p 5,1,4
Finally, it is possible to request that some corner of some object be placed 
at a specific point, so that arithmetic is not necessary:
.nj.nf.b 1
	ellipse '1'
	ellipse '2' with .nw at last ellipse.se
.j.f.b 1
places the northwest corner of ellipse 2 at the southeast corner of ellipse 
1:
.figure 8
This facility is especially useful for positioning boxes.
.hl 1 REFINEMENTS AND EMBELLISHMENTS
.p 5,1,4
Besides the basic facitilies illustrated in the previous section, PIC 
provides a number of other services.  This section gives a quick look at 
some of them.
.p 5,1,4
There are a variety of attributes not mentioned earlier.  Lines and boxes 
may be dashed or dotted.  Lines may be chopped by a specified amount at 
the end.
Any object can be made invisible, which is often a convenient way to force 
positioning without drawing anything.  For example, a picture with 
invisible circles ("circle invisible") looks like this:
.nj.nf.b 1
	circlerad = 0.2
	SORT: circle invisible 'SORT'
	downright
	arrow from SORT.se -_>
	LIST: circle invisible 'LIST'
	downleft
	arrow from LIST.sw -_>
	arrow from SORT.sw -_>
	POSET: circle invisible 'POSET'
	arrow from POSET.sw -_>
	circle invisible 'TRIV'
	arrow downright from POSET.se -_>
	circle invisible 'BOOL'
.pg
.j.f 
.p 5,1,4
Splines are actually cubic B-splines.  The spline is specified by a set of 
"guiding points" that are not acturally on the curve (except for the ends),
but control the position of the curve, as illustrated below:
.nj.nf.b 1
.require "spline.rno"
.figure 14
.j.f.b 1
The starting point, the guiding points and the end point should be such that 
either the x coordinates or the y coordinates must be all increasing or all 
increasing. You can't ask for a spline that will zig-zag both in the x and y 
directions. PIC will attempt to use the x coordinates first to make the 
spline. If x values are not increasing or decreasing, PIC will report the 
absence of such an order with a message.
It will use the y coordinates to generate the spline. If this fails too, PIC 
will give up any hope of making a spline. You will receive a message 
indicating this loss of hope.
.p 5,1,4
Arcs may be specified  in  a variety of ways.  By default, "arc" in 
isolation requests a 90 degree counter-clockwise arc.  It is also possible 
to specify the the radius, the start, and the end of the arc in 
arbitrary combinations.  PIC will fill in the missing values.  For instance, 
only the start and end were given for the arc in the previous section; the 
radius was computed from the end points.
.p 5,1,4
It is possible to ask for a point some fraction of the way between one point 
and another, as in
.nj.nf.b 1
	1/3 between top of last box and bottom of last circle
or
	box
	arrow from 1/3 between last box.ne and last box.se
	arrow from 2/3 between last box.ne and last box.se
.j.f.b 1
which produces
.figure 4
.pg
.hl 1 LARGER EXAMPLES
.p 5,1,4
It is hard to get an accurate feeling for a language by studying it 
components in isolation. This section contains several larger examples that 
illustrate how the pieces of PIC works together.
.p 5,1,4
The first example shows PIC working about as well as possible:
.nj.nf.b 1
.require "cpass.rno"
.j.f
.pg
The following draws a expression tree.
.nj.nf.b 1
.require "tree.rno"
.pg
.figure 35
.pg
.j.f
The following example makes use of the DECUS macro package. The "__macro"
directive introduces the macro named "ndblock" which is then invoked within
the PIC commands. The file containing the PIC commands was first processed
through the macro program.
.nj.nf.b 1
origin = ( 2,3 )

__macro(ndblock,box width boxwid/2 ht boxht/2 
        down; box same with .top at bottom of last box
        box same with .top at bottom of last box; box same )

boxht = 0.2; boxwid = 0.3
down; box; box; box; box ht 3_*boxht '.' '.' '.'
L: box; box
box invisible width 2_*boxwid 'hashtab: ' with .east at first box.west
right
Start: box width 0.5 with .sw at first box.ne + (.4,.2) '...'
N1: box width .2 'n2'
D1: box width .3 'd2'
N3: box width .4 'n3'
D3: box width .3 'd3'
box width .4 '...'
N2: box width .5 'n1'
D2: box width .2 'd1'
arrow right from second box
ndblock
spline -_> right .2 from fourth last box to N1.sw + (0.05,0)
spline -_> right .3 from third  last box to D1.sw + (0.05,0)
arrow right from last box
ndblock
spline -_> right .2 from fourth last box to N2.sw - (0.05,.2) _\
          to N2.sw + (0.05,0)
spline -_> right .3 from third  last box to D2.sw - (0.05,.2) _\
           to D2.sw + (0.05,0)
arrow right 2_*arrowlen from L
ndblock
spline -_> right .2 from fourth last box to N3.sw + (0.05,0)
spline -_> right .3 from third  last box to D3.sw + (0.05,0)
rad = .3
circle invisible 'NDBlock' at last box.east + (1.2,0)
arrow dashed from last circle.west to last box.east

box invisible width 2_*boxwid 'NDTable: ' with .east at Start.west
.j.f
.pg
.hl 1 IMPLEMENTATION
.p 5,1,4
PIC has been implemented in MODULA-2. 
The PIC language is defined in EBNF form. A first pass (implemented as a 
recursive decent parser) over the pictures collects the primitives and 
evaluates their attributes, primarily to determine the relative positions of 
the objects. A second pass generates the graphics output in a device 
independent format. The device independent output can then be submitted to 
the respective graphics device driver for actual plotting.
.p 5,1,4
As indicated before, the first picture command must specify the origin for 
the picture; the UNIX PIC is a preprocessor for TROFF and thus can let TROFF 
worry about picture positioning. None of the VAX formatter could be used in 
a similar fashion. It is a burden, but I hope the user of PIC could live 
with the limitation. The origin specifies the center or the start of the 
first picture element.
.p 5,1,4
The intention behind using separate graphics device drivers was to allow for
batch processing of the picture commands. Thus the user can do the actual 
plotting at his or hers convenience. Currently, drivers are available for 
Hewlett-Packard (HP)
HP-7221B and HP-7221T plotters, DEC VT125 
and HP plotters that use the HP-GL graphics 
language (7220, 7470, 7475, 7550 etc). (Note that the newer DEC terminals VT240
and VT241 recognize the Regis graphics langauge; they do not support it 
however.)
I am working on drivers for TEKTRONICS plotters,
.p 5,1,4
The macro processing and picture "blocks" facilities of the UNIX PIC have 
been left out. I hope to implement them in the future. The user may note 
that a number of very powerful macro processing packages are already 
available in the DECUS program library.
.p 5,1,4
The user may choose to write programs that generate PIC commands. An elegant 
approach would be to write a recursive, tree traversal program that takes
a binary tree and generates PIC commands to 
plot the nodes. An inorder traversel would the do the job.
.hl 1 USING PIC ON THE VAX
.p 5,1,4
PIC can be invoked by the following command:
.nj.nf.b 1
	^*pic piccmdfile grafile device [px#py] [-Echo] [-Pchain]\*
.j.f.b 1
where "piccmdfile" is text file that contains the picture commands,
"grafile" is the file where PIC will place the plotting instructions for the 
device drivers. "device" can be one of the following:
.b 1
.indent +5
vt125, hp7220, hp7221, hp7470, hp7475, hp7550
.b 1
Make sure that your system manager has set up the logicals and foreign commands
for PIC and the graphics drivers. On our system, i.e at UCCS, if one types
"VUG" once after logon, all the necessary set up is automatically performed.
Here are the DCL commands required if you have to do it yourself:
.b 1
.lm +5
.literal
$ assign user3$:[engr.thesis.saslam.mod.picbin] pic$bin
$ assign 'f$logical("pic$bin")           pic$tables
$ ddhp7221  :== $pic$bin:ddhp7221
$ ddhp7475  :== $pic$bin:ddhp7475
$ ddhp7550  :== $pic$bin:ddhp7550
$ ddrgl     :== $pic$bin:ddrgl
$ ddterm    :== $pic$bin:ddterm
$ pic       :== $pic$bin:pic
.end literal
.b 1
.lm -5
If the device is one of the HP's,
PIC by default assumes that you are going to generate the picture plot on a 
paper 11 by 8.5 inches and lay it on the platten on the plotter with the 11 
inch side horizontal. If you are going to use a bigger paper size or 
orientation, follow the device with the size of the paper in inches as
"px#py". Don't place the paper size within "[]" on the command line. The 
"[]" indicate the command line parameter is optional. 
If you specify the "-Echo" option then PIC will echo each line of command
before it is parsed. This option will be useful whoe debuging PIC commands.
The "-Pchain" causes PIC to print a detailed list of picture elements. This
includes the location of each picture element, its size and other attributes.
This option can be used to find out where and how the picture is going to
be drawn.
.p 5,1,4
After PIC has successfully placed the graphics output to the "grafile" you 
specified, invoke the respective graphics device driver with the "grafile" 
as the input. "ddrgl" is the driver for VT125, "ddhp7221" is the 
driver for HP7221B and HP7221T plotters. So, for example, if your picture 
commands are on a file called "tree.cmd", here is how to get the plot on a 
14#by#11 inch paper on the HP7221B plotter:
.nj.nf.b 1
	_$ pic tree.cmd tree.gf hp7221 14.0 11.0 -e
	_$ ddhp7221 tree.gf
.f.j.b 1
Make sure that you have placed the paper in the correct position on the 
plotter, i.e, 14 inch side horizontal. To get the picture on a VT125,
log on the VAX, and then the following:
.nj.nf.b 1
	_$ set term_/regis_/nowrap
	_$ pic tree.cmd tree.gf vt125
	_$ ddrgl tree.gf -h
.j.f.b 1
The "set term_/regis_/nowrap" are directives for VMS_/DCL, telling it to 
pass the graphics commands to the VT125 untouched. 
The "-h" is an option specific only to the
device driver for VT125; it directs the driver to dump the
screen image to the hard copy printer attached, e.g, LA100. Of course, you
would not specify the "-h" if you donot have a printer attached.
.p 5,1,4
To view the data present in any of the graphics files generated, "ddterm"
can be used. Give it the graphics file name and it will display on the
terminal the data that is present in the file. This can be used to find
out the actual coordinates associated with the picture. Keep in mind that
the graphics file is a binary file, fixed size records, 512 bytes per record.
Don't try to list it on the terminal; the terminal will go haywire. Use 
"ddterm":
.nj.nf.b 1
	_$ ddterm tree.gf
.j.f.b 1
.p 5,1,4
Here are all the device drivers currently available:
.nj.nf.b 1
.ts 10 20
	ddrgl	for VT125 ( and VT240, VT241 )
	ddhp7221	for HP7221B and HP7221T
	ddhp7475	for HP7475 using HP-GL
	ddhp7550	for HP7550 using HP-GL
	ddterm	for looking at a graf file
.b 1
.j.f
"ddhp7475" or "ddhp7550" can be used for other HP plotters that use the HP-GL
instruction set. Quite often the HP plotters are connected to a terminal line
all their own, or set up as a spooled device. The drivers for the HP plotters
that use the HP-GL commands output the graphics instructions to fortran
file code 6 (the drivers are written in Modula-2 but call on the FORTRAN 
routines in the HPISPP package to do the actual plotting). If the plotter
is connected to one of the TT lines, you would need to make an assignment
as follows:
.b 1
.i +5
_$ assign/user ttg2: for006
.b 1
For your system, look up the device code#-#ttg2: pertains to the VAX at UCCS.
If the plotter sits in between a terminal and the VAX, you need not worry
about assignments. The same holds for spooled enviroments. The driver for
the HP7221 plotters reads from fortran file code 5 and writes to file code 6.
.pg
.hl 1 FORMAL DESCRIPTION OF PIC COMMANDS -- The PIC grammer
.p 5,1,4
Here is the formal grammer for PIC. The recursive decent parser parses this 
grammer. The keywords are bolded. ^*You must not use the keywords as labels 
or identifiers in your picture commands\*.
.sp 1
.ts 22 55
.nj.nf
.b 1
PicProg -->	  PicOrigin cmdseparator PicCmd  EOF 
.b 1
PicOrigin -->	  ^*origin\* "=" "(" RealNumber "," RealNumber ")" 
.b 1
cmdseparator -->	  ";" _| NEWLINE
.b 1
PicCmd -->	  Command { cmdseparator Command  }
.b 1
Command -->	  Direction
	_| DefaultDimension "_=" Arex
	_| Identifier "_=" Arex
	_| ^*move to\* Location
	_| [Label] PicElement
.b 1
Direction -->	  ^*up\*_|^*down\*_|^*left\*_|^*right\*
	_| ^*upright\*_|^*upleft\*_|^*downleft\*_|^*downright\*
	_| ^*cw\*_|^*acw\*
.b 1
DefaultDimension -->	  ^*boxht\*_|^*boxwid\*_|^*cht\*_|^*cwid\*
	_| ^*majax\*_|^*minax\*_|^*rad\*_|^*linelen\*_|^*arrowlen\*
.b 1
Arex -->	  term { "-"_|"_+" term }
term -->	  primary { "_*"_|"_/" primary }
primary -->	  "-" primary
	_| element
element -->	  "(" Arex ")
	_| DefaultDimension
	_| Identifier
	_| IntegerNumber
	_| RealNumber
.b 1
Label -->	  Identifier":"
.b 1
PicElement -->	  BasicElement AttributeList
	_| AttributeList
.b 1
BasicElement -->	  ^*arc\*_|^*arrow\*_|^*box\*_|^*circle\*_|^*ellipse\*
	_| ^*line\*_|^*spline\*

.pg
.b 1
AttributeList -->	  Attribute { Attribute  }
.b 1
Attribute -->	  ^*solid\*_|^*dashed\*_|^*dotted\*_|^*invisible\*_|^*same\*
	_| ^*chop\* [ Arex ]
	_| ^*ht\* Arex
	_| ^*width\* Arex
	_| ^*rad\* Arex
	_| ^*majax\* Arex
	_| ^*minax\* Arex
	_| ^*from\* Location
	_| ^*to\* Location
	_| ^*at\* Location
	_| ^*with\* CompassPoint ^*at\* Location
	_| Direction [Arex] [ ^*from\* Location ]
	_| ArrowHead
	_| ^*color\* ColorType
	_| QuotedString
	_| Location
.b 1
ArrowHead -->	  ^*-_>|<-_>|<-\*
.b 1
Colortype -->	  ^*black\*|^*blue\*|^*green\*_|^*red\*
	_| ^*cyan\*_|^*magenta\*_|^*yellow\*_|^*white\*
.b 1
QuotedString -->	  '[CF][CF] character { '' _| character } '
.b 1
CF -->	  ^*_\c(bk\*_|^*_\c(bl\*_|^*_\c(rd\*_|^*_\c(gr\*
	_| ^*_\f(hd\*_|^*_\f(st\*_|^*_\f(oe\*_|^*_\f(rm\*_|^*_\f(sc\*
.b 1
Location -->	  Coordinates
	_| CompassPoint [ ^*of\* Primitive [ Modify ] ]
	_| Primitive[CompassPoint] [ Modify ]
	_| Identifier[CompassPoint] [ Modify ]
	_| FracWay
.b 1
Primtive   -->	  [ PrimCount ] BasicPrimtive
.b 1
PrimCount  -->	  ^*first\*_|^*second\*_|^*third\*_|^*fourth\*_|^*fifth\*
	_| ^*sixth\*_|^*seventh\*_|^*ninth\*_|^*tenth\* _[^*last\*_]
.b 1
Coordinates -->	  "(" Arex "," Arex ")"
.b 1
CompassPoint -->	  ^*.top\*_|^*.bottom\*_|^*.center\*_|^*.start\*_|^*.end\*
	_| ^*.east\*_|^*.west\*_|^*.north\*_|^*.south
	_| ^*.ne\*_|^*.nw\*_|^*.se\*_|^*.sw\*
.b 1
Modify -->	  Addop Coordinates
Addop -->	  *_+ _| *_-
.b 1
FracWay -->	  intfrac ^*between\* Location
	         ^*and\*     Location
intfrac -->	  IntegerNumber "_/" IntegerNumber 
.j.f
.pg
^&NOTES.\&
.list
.le;Commands can be continued on more than one line by placing a "_\" before 
the end of line. Text strings, however, must not be broken across line 
boundaries.
.le;Real numbers in expressions cannot be in scientific form. Thus, "1.25e-2"
will invite trouble.
.le;The maximum string length is 80 characters. Same maximum holds for 
identifiers and labels. A maximum of 5 strings can be associated with
each object.
.le;The two letter font directive that can be placed at the beginning of a 
text string signify the following:
.lm +5
.nj.nf.b 1
hd   hardware font
st   enhanced stick
oe   old english (gothic)
rm   roman triplex
sc   script
.j.f.b 1
.lm -5
Availability of fonts is function of the graphics device being used. VT125, 
for example, does not have any. HP7221B has all of the above fonts.
The color directives are:
.lm +5
.nj.nf.b 1
bk  black
bl  blue
rd  red
gr  green
.j.f.b 1
.lm -5
Note that not all the colors described in the grammer may be available.
.le;To make the job of the parser, and perhaps avoid unexpected results, order
the attributes such that the attributes that affect the dimensions of an 
object ^*precede\* the attributes that define the positioning. Thus say
.lm +5
.nj.nf.b 1
circle ^*rad 0.55\* with .center at last circle.center 
.b 1
.lm -5
instead of
.b 1
.i +5
circle with .center at last circle.center ^*rad 0.55\* 
.b 1
.j.f
.le;^*CAUTION\*:#when a motion i.e, lines, arrows, spline, are followed by
a direction and possibly distance to move in that direction, the current
default direction is changed. So after the picture element, reset the
default direction to what you want it to be. See the example when the splines
were described.
.end list
.pg
.b 2
^&Graphics_ device_ specifics\&
.list "o"
.le;The maximum page size for the HP7221B and HP7221T is 14 inches by 11
inches. Make sure that you set your origin and picture locations with the 
in accordance with the page size you intend to use. The plotter's platten does 
not look too neat with pen marks.
.le;To keep the picture on the screen when using the VT125,
the maximum coordinate range is 5.8 inches by 3.622 inches.
.le;You can select an infinite set of character heights and widths when using 
the HP plotters. VT125, which is driven by the ^*Regis\* graphics package, has 
a set of sixteen character sizes available. Thus when you specify character 
height of width, PIC rounds up or down to the nearest available character 
size.
.le;The print screen feature of the VT125 keyboard can be used to dump the 
picture onto a LA100. This can also be achieved by using the "-h" in the
"ddrgl" command line.
.le;Pen ports on the HP plotters and the color you specify in your PIC 
commands correspond as follows:
.nj.nf
##pen port   PIC color
###1          black
###2          blue
###3          green
###4          red
.j.f
.end list