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 LeFebvreYou 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: