An old little language for drawing diagrams. Originally a troff (and nroff and groff and ...) preprocessor which was part of the UNIX Documenter's Workbench text tools supplied by AT&T and/or BSD. Nowadays, that pic is dead, but GNU pic continues the tradition. Even nicer, it can produce TeX output at the drop of a -t switch. ESR has a very well-written tutorial and reference entitled "Making Pictures With GNU PIC".
While pic is usable with TeX (indeed, I almost never use it with *roff, preferring TeX), its syntax is a bit like the syntax of other *roff preprocessors, such as eqn, tbl and grap. grap is a pic preprocessor, but as it is no longer available there is little point in dwelling on the mind-bending thoughts of prepreprocessors... Therefore I shall use pic in *roff mode. On a Linux or similar system, a syntax for processing pic files could be
pic < input-file.pic | groff > output-file.ps
(or
pipe the groff output to a
PostScript viewer such as
gv or
ghostview).
Basic drawing
Like any UNIX Bell Laboratories tool, pic has a simple, readable syntax, which is almost but not quite totally unlike the syntax of every other UNIX Bell Labs tool. (There is no need to worry -- GNU pic extends the syntax of "classic" pic in a simple, readable and utterly different way...). So the easy things are very easy:
.PS
box "A"; arrow; box "B"
.PE
draws a picture rather like this one:
+-----+ +-----+
| A |----->| B |
+-----+ +-----+
except that pic produces printed quality, and I produce low-level cheap
ASCII art imitations. Everything between the ".PS" and ".PE" troff-like
commands is considered a pic program; pic will ignore all the other text, passing it through to programs further down the pipeline. This lets pic work with *roff and TeX.
pic commands ask for some object to be drawn: box, circle, line, arc, ellipse, arrow, are all provided, as well as macros. After a command come various options. Commands end at the end of the line, or with a semicolon. The most common option is just "some string" -- that string will be printed, centered, on the object. You can also use just "some string" as the object, making pic draw that string.
After drawing any object, pic moves in the default direction. The default default direction is "right" -- that's why we got a box, an arrow, and a box going from left to right. Some commands -- like "arc" -- can change the default direction, which is nice. You can change the default direction by using a direction name as a command:
.PS
down
box "two" "lines"
arrow
ellipse "The" "End."
.PE
draws a box above an arrow above an ellipse.
Note also the use of multiple strings as options -- the strings are displayed on separate lines.
Default directions are convenient, but don't always do what you'd expect. Luckily pic has gazillions of positioning directives, which let you do what you need to do. Of course, there are so many directives that it can be hard to decide which ones you really need. The area which causes the most difficulties is when you want to change directions. To draw a closed loop of boxes and arrows, you can say:
.PS
right; box "1"; arrow
box "2"; down; arrow from last box .s
box "3"; left; arrow from last box .w
box "4"; up; arrow from last box .n
.PE
(There are many other ways to get the same effect).
You can also name parts of your picture using LABEL: object. Saying "arrow from BIGBOX .nw" can be easier than saying "arrow from 18th box .nw" (although both syntaxes work). Naming parts is especially useful when using a macro. For a final simple example, here's a simple organization chart of where you work:
.PS
right
P: box "Z. President"
define vp {
line from P.e right 0.1 then down $1 then right 0.1
box height 0.35 width 0.8 $2
}
vp(-0.6, "VP RND")
vp(-0.2, "VP S&M")
vp( 0.2, "VP Cloud" "Control")
vp( 0.6, "VP Self" "Advancement")
.PE
pic is very old-fashioned by today's (sub-)standards. But it excels in programmatic creation of diagrams, or in letting somebody with as poor mousing skills as mine prepare a semblance of a diagram.