Edition 8 Version of pic (July 1985).

[unix-history] / usr / src / local / ditroff / ditroff.okeeffe / pic / UNDOC

May 85:

"solid" is now a valid (though uninteresting) attribute.

Mar 85:

Limited amount of point arithmetic:
	point +/- point
works

Dec, 1984:

reset varlist
	resets built-in variables in list to default values.
	empty list resets everything.

sprintf("format", exprlist)
	returns a text string suitable for use anywhere "..."
	can be used.

sh X anything X
	passes "anything" to a shell for execution after
	replacing any defined terms in it.

Nov, 1984:

line expr and move expr are treated as line/move by expr
in current direction.

The -D option has been rendered obsolete -- all output is
produced with \D commands.  The -T option is also 
meaningless -- the output is independent of typesetter.

A new variable "arrowhead" controls printing of arrowheads,
by defining the number of lines printed in a little fan.
Default is 2;  values around 7 give a filled-in head;
other values are basically worthless.  Arrowheads on arcs
are now tilted somewhat in an attempt to improve their
appearance.

"undef foo" removes the definition of foo.

July 1984:

The functions log, exp (both base 10), sqrt, sin, cos, atan2(,),
max, min (2 arguments only), int, and rand (which returns a
float random on [0,1)) are now available,  stolen directly
from grap.

Added copy, for and if from grap:
	copy "file"
	copy "file" thru X macro body X
	copy thru X macro X [until "str"]
	for var = expr to expr [by expr] do X anything X
	if expr then X anything [else X anything X]

In a copy, any .PS or .PE is discarded [sic], so copied files
can be nested without editing.  .PS <file still works
but its use is discouraged.

In an if, you can also test "string1" == "string2" or
"string1" != "string2"

The text primitive is now more systematic:
"..." ".." "." makes an invisible object with
properties much like a box.  Height and width
are settable:  explicit ht and wid modifiers
affect a specific instance;  variables textht
and textwid affect all subsequent occurrences.
"textht" is the height of one line, so the height
of n strings is n*textht.

Added code from Eric Grosse to correctly compute bounding
box for arcs.  Also defined corners for arcs as same as
corresponding circle, an idea due to Tom Cargill.

Limits on text strings, attributes and objects grow until
memory limit reached.

Permits E format on input numbers.

Output produced in inches, not units, so somewhat more
typesetter-independent.  The environment variable TYPESETTER
is examined.

Saves and restores fill state around .PS/.PE.

.PS wid ht
can be used to set width and height separately for picture;
default ht is to scale in same proportion as width (as before).


Dec 10/81:

The "scale = ..." construction has been reinstated:
if
	scale = 100
or some such appears in a picture, all numbers in that
and subsequent pictures will be scaled by 1/100.
Default scale is 1.0.

Oct 8/81:

I have finally installed sensible floating-point
numbers in pic.  This means that the trailing "i",
as in 1.25i, is no longer necessary:  all numbers
are taken to be in inches.
Furthermore, expressions may now use numbers like
1.25 instead of circumlocutions like 5/4.
It is now best to enter dimensions and positions simply
in terms of inches, as in "box at 1,2" instead of in terms
of internal units (which used to be "box at 200,400").
Internal units are no longer used.

I will be glad to assist with conversion if necessary;
opic will remain around for a while too.

New May, 1981:

0.  Diagnostics:
	Error reporting is better; error location is marked
	with a ^ at the point in the input where the error was detected;
	line numbers are more accurate when define's are used.

1.  Shorthand for points
	( place1 , place2 ) now refers to the point ( place1.x, place2.y ),
	as it does in i.

2. Blocks
	Any sequence of pic statements may be enclosed in [...] to form
	a block, which can be positioned rather like an ordinary box.
	Typical constructions look like
		box ...
		[ box; circle; arrow; whatever ] with .ne at last box.sw
		move to top of 2nd last []
	"last"-type constructs treat blocks as a unit and don't look
	inside for objects.  Blocks have the same compass corners as
	boxes (determined by the bounding box); in addition it is
	possible to position them by placing either an absolute 
	coordinate (like 0,0) or an internal label (like A) at some
	external point.  Thus:
		[ ...; A: ...; ... ] with .A at ...
	You can use "last []" just like "last box".
	Blocks join with other things like boxes do (i.e., at the
	center of the appropriate side).  It's not clear that this
	is the right thing to do, so it may change.

	Names of variables and places within a block are local
	to that block, and thus do not affect variables and places
	of the same name outside.  You can get at the internal
	place names with constructs like
		last [].A
	or
		B.A
	where B is a name attached to a block like so:
		B : [ ... ;  A: ...;  ]

	When combined with define statements, blocks provide
	a reasonable simulation of a procedure mechanism.

	Blocks nest, but the code is shaky; let me know if
	something suspicious happens.
	It is currently possible to look only one level deep
	with constructs like B.A, although A may be
	further qualified (i.e., B.A.sw or "top of B.A" are legal).

3. Flyback
	If .PF is used instead of .PE, the position after printing is
	restored to where it was before the picture started.
	("F" is for "flyback".)

4. "Between" positions
	It is now possible to specify a position somewhere between two
	other positions either by the phrase 
		expr of the way between position1 and position2
	or by the notation
		expr <position1, position2>
	where expr is some number like 0.3333 and the positions are anything
	like corners, labels, etc.  The result is a new position which is
	"expr" of the way along a line from position1 to position2.  Naturally
	expr can be bigger than 1 or negative.  "of the way" is optional.


These are changes since the TM was issued in June, 1980:

.PS <file
	causes input to come from "file".
	the .PS evaporates, so "file" has to
	have balanced .PS/.PE pairs.

splines are here.  To get smooth curves,
	"spline" followed by a set of up, down, from, to, etc.
	causes a B-spline to be drawn using the specified
	points to guide it.  the word "then" can be stuck
	in to separate unrelated groups of relative motions.
	Arrows can go on either end.
	E.g., spline from 10,20 up 30 right 40 then left 50 then \
		down 20 to 100,200 to 300,350 ->

Lines have been generalized somewhat, so you can use the same
	construct as for splines, to specify a path rather than
	just a single segment.