Getting PIC-y

[phil at RICE.ARPA]

From:  William LeFebvre <phil at RICE.ARPA>

Now that I have fumbled around with pic for awhile, I have a few things
I would like to share with the rest of the Unix community.

In reference to the letter I sent a few days ago, thanks to all who
responded to it.  It turns out (as was pointed out to me by several
people, including one at Rice) that the 4.1 C-preprocessor didn't care
if it hit the end of file inside a #if or #ifdef.  Apparently, neither
did the Version 7 preprocessor.  I can only assume that pltroff.c, as
distributed, has a #endif missing in it.  Obviously, this endif needs
to go at the end of pltroff.c.  This must be done on 4.2 because the
C-preprocessor distributed with 4.2 *does* care if there is a missing
#endif.  Beware all ye who desire to recompile pic under 4.2!

There is a very minor bug in pic.  Line 109 of pltroff.c looks like
this:

	fprintf(stderr, "picture too high or wide");

There should be a newline at the end of the string (I told you it was
minor).

There is also a fairly major oversight.  While you are fixing that
little bug, look one line above that at line 108.  It says:

	if (xconv(xmax) >= 8192 || yconv(ymax) >= 8192) {	\
		/* internal troff limit: 13 bits for motion */

(that's all one line in the source).  Well, this works great if you are
using a machine such as the CAT/4 that has medium resolution.  But if
you want to generate pic for something that uses a very high
resolution, half of your pictures won't get made because they are "too
high or wide".  Clearly these should be based on the external variable
"res" that is set in main.c according to the device that is specified
(or defaulted).  How about something like "11*res" instead of the constant
"8192"?  Of course that assumes that the paper is 11 inces long.  It
would be even better to just use the paperwidth and paperlength values
found in the DESC.out file for that device (these files are built from
ascii descriptions of the various devices that one wants to use ditroff
on -- all you ditroff wizards will know what I am talking about).

Which brings me to the flame of this article.  Why oh why didn't the
people who wrote pic and rewrote eqn use the tables that troff uses?
The DESC.out table contains all the information they will ever need
about the device in question -- the horizontal and vertical resolution,
the paper width and length.  Clearly this would be better than a chain
of if ... else statements with strcmp-s for "known" names.  This means
that someone (like me) has to go diddling in the source to make pic and
eqn usable on machines like the Xerox 2700.  This is stupid!  I guess
that these things were written or rewritten before ditroff had taken
complete form, but it wouldn't be that hard to add this stuff.  They
went to the bother of changing half of troff, they could have gone a
little farther and made these trivial changes to the preprocessors.
Now I have to go do it.  In fact, I am very seriously thinking of doing
so.

                                William LeFebvre
				Department of Computer Science
				Rice University
                                <phil at Rice.arpa>