Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uw-beaver
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver
Newsgroups: fa.laser-lovers
Subject: plot, titroff, and pltroff
Message-ID: <1567@uw-beaver>
Date: Tue, 17-Sep-85 04:58:06 EDT
Article-I.D.: uw-beave.1567
Posted: Tue Sep 17 04:58:06 1985
Date-Received: Wed, 18-Sep-85 05:14:27 EDT
Sender: daemon@uw-beaver
Organization: U of Washington Computer Science
Lines: 26

From: William LeFebvre 

You must be referring to the pltroff.c that is part of pic.  That's the
only pltroff I can find in my ti-troff distribution.  It is true that
this can be modified to act as a plot interface to troff.  But just to
set the record straight, it is NOT a failed attempt at implementing a
plot interface.  I would describe it as being a plot-like interface (or
an interface loosely based on the plot library) that was written
specifically for pic.  It is part of pic and therefore shouldn't be
changed.  It is what pic uses to produce troff output.  The calling
conventions are very similar to plot, but as an example of places where
they differ:  "label" has two extra arguments, there is an "ellipse"
function (but I have long thought that plot needs an ellipse command),
and all the arguments that specify points are passed as doubles rather
than ints.  If you want to change it, do yourself a favor and make the
changed version completely separate from pic.

It is a worthwile idea.  I was just thinking earlier today how wild
it would be to have a plot library that produced troff, or even pic.
That opens up some very interesting possibilities.

			William LeFebvre
			Department of Computer Science
			Rice University
			
                        or, for the daring: