fjn@Purdue.ARPA (Francie J Newbery) (05/06/85)
We would like to be able to send some of our large troff jobs off to be run on a remote machine. When the users input contains .so's to source files (which reside only on the local machine) this is a potential problem. We can handle the simple case of a .so of the form: .so <filename> by simply running the input through soelim before sending it to the remote troff machine. Unfortunately, the so's are often used in combination with define string macros such as .ds. Currently, soelim is not able to handle something of the form: .ds // /usr/lib/ms/ .so \*(//s.cov Has anyone else come across this problem before and maybe developed a better version of soelim that would take these string maninpulations into account? If so, please contact Francie Newbery (fjn@Purdue). Francie Newbery
ed@mtxinu.UUCP (Ed Gould) (05/10/85)
> We would like to be able to send some of our large troff jobs off to be > run on a remote machine. When the users input contains .so's to source > files (which reside only on the local machine) this is a potential problem. > > We can handle the simple case ... > Currently, soelim is not able to > handle something of the form: > > .ds // /usr/lib/ms/ > .so \*(//s.cov > > Francie Newbery We gave up at Berkeley when confronted with this problem. There, we were dealing with a typesetter connected to just one machine on a network, and wanted to queue the outputs for operators to run. So far as I know, there's no general solution short of running all of troff locally. The string substitution form you describe probably covers 90% or more of the cases, but people put .so's behind .if's as well. Those are the hard ones. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146
roy@phri.UUCP (Roy Smith) (05/14/85)
> We gave up at Berkeley when confronted with this problem. [...] So far as I > know, there's no general solution short of running all of troff locally. This is only marginally related to the above topic, but here goes anyway. After working with various flavors of n/troff for the past 7 or so years, I've come to the conclusion that we just plain need something better. A typical print command around here looks like: "soelim manuscript | bib -t pnas | tbl | neqn | nroff -me -Tnec-t | prt" Prt is a filter I wrote which pumps its standard input through a crt's printer port. I've added a new capability to terminfo, called "slave". I set TERM to "vt100-nec" which is exactly like a vt100 except that is has the slave capability set to "nec"; prt looks up the slave type and initializes the nec right after turning on printer controller mode. Anyway, because there are 6 different processes going, you have to stand on your head to talk to each one without confusing the others. Using $ as the neqn delimiter is a pain because you can't easily use $'s as arguments to macros you want to define. Before we started using tbl a lot, all of us here gradually shifted over to using "|" and that worked fine. But tbl generates "|" in it's output, so that's no good. Also, if you want to have citations in your bib data base with stuff like $ BETA -galactosidase $ in the titles (we do), you have to make sure that your neqn delimiter is "$" when neqn sees the bibliography. So, people learned to flip back and forth between various delimiters. You can't put double quotes in the bib data base because that confuses the bib macros, so we have learned to use \(lq and \(rq. It goes on and on. Nroff steadfastly refuses to underline greek characters or punctuation unless you hack the terminal driver tables (but genetic notation often requires it). So, you learn to do horrible things with local line motions. Our poor secretaries have to learn how to figure out how many backslashes you need to protect something with to make it get interpreted at the right time. I'll admit that compared to the competition (no, I've never used TEX, but from Knuth's book, it looks like it would be too tough to teach non-computer types) nroff and all it's various pre/post processors are pretty good, but I think we've really pushed n/troff to it's limit and beyond. I'm waiting for the day when we I can get some Suns in here so we can use their "Macwrite with a higher education", but I don't see how that will interface easily with bib (people around here have finally learned to love bib, and won't want to give it up). So, the bottom line is, I wish there was something better, but don't know what. -- allegra!phri!roy (Roy Smith) System Administrator, Public Health Research Institute
jbn@wdl1.UUCP (05/15/85)
One could embed some remote file access capability in the remote troff; it's easy enough to write a remote file access server if you are willing to accept 25% of local file system performance. There are a couple of these things kicking around, such as the Newcastle Connection. John Nagle