phil@RICE.ARPA (07/25/84)
From: William LeFebvre <phil@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@Rice.arpa>
lee@rochester.UUCP (Lee Moore) (07/27/84)
Actually, I claim that Bill's fix to pic/pltroff.c is wrong. The comment says: /* internal troff limit: 13 bit for motion */ This means that the size of the bit field for representing motions inside of old TROFF is 13 bits. In typesetter-independent, this field was changed to 15 bits. Thus the line should be: if (xconv(xmax) >= 32728 || yconv(ymax) >= 32768) { /* ... */ This internal representations are discussed in Kernighan's report "A Typesetter Independent TROFF" (Bell Labs CS TR 97). -- = lee@rochester rochester!lee =
phil@RICE.ARPA (07/28/84)
From: William LeFebvre <phil@RICE.ARPA> Lee Moore is quite right on that one. Thanks for pointing it out. I read that technical report last fall, but I didn't see the correlation at the time. But I still think that the resolution information should be gotten out of the ditroff device information files (DESC.out). William LeFebvre Department of Computer Science Rice University <phil@Rice.arpa>