ronald@robobar.co.uk (Ronald S H Khoo) (06/20/91)
Michael John Staley <staley@lad.med.utas.edu.au> wrote: > the Text Processing package was the 'thing' for me > the product is Xenix based. > Neverthless I was assured that the product did indeed work on a SCO > Unix platform It does indeed. Installing it was a pain, but SCO knows about that one :-) > I found that the its use was VERY limited in that I could > not do things like eqn, tbl etc. I have used the eqn and tbl from the XENIX text processing system under SCO UNIX with reasonably good results, using psroff 2.0. Can you explain just why you can't use tbl and eqn? I can. > I experienced all sorts of nasty things such as > ...core dumped... messages when it was used to man my man.LOCAL things. This is likely due to a bug in the SCO manual page "rmb" program. Under SCO XENIX this is is somewhere like /usr/man/bin, under SCO UNIX it's in /usr/bin. I rewrote a slightly "improved" (heh) version of rmb, which I append to the end of this message. Please tell me if this cures your problem. SCO's rmb dumps core if you give it lines with the nroff underlining and boldfacing overstrike with ^H trick. Probably gets with a fixed buffer or something like that. tut tut :-) > My problems have increased recently as I have imported psroff 3.0 which > requires a GOOD version of nsroff. Actually PSROFF wants troff. The SCO troff is "good enough". It's a bit buggy, but not seriously so -- I used it for several years, first with the "thack" postscript driver, then psroff 1.0, then psroff 2.0. I'm still waiting for Rich Salz to post 3.0... :-) > Where can I obtain a good version > of nroff which has all the bits and which will run with SCO Unix and > my new psroff 3.0. Well, you can drop the SCO troff and psroff completely, and get GNU troff instead (you will want to retain the ms and mm macro packages from the text processing system -- /usr/lib/tmac and /usr/lib/macros) You can FTP the Xenix binaries which I compiled from unix.secs.oakland.edu. Yes, I use them regularly on SCO Unix. (Actually I now use a slightly newer version, but I did use the old one for months) You will still need the documentation from the SCO text processing system. The other thing to do is to get as many SCO customers as you can to lobby them to license and resell DWB 3.2 which is the latest version of commercial troff from AT&T. In fact, AT&T do sell binaries for System V/386, which should work on SCO Unix, (has anyone tried? Please do post !) but no one's going to support your using that under SCO, so LOBBY SCO. Anyway, here's my rmb.c. It's *different* from SCO's, but you should be able to drop it in. Heh. /* * rmb -- removes extra blank lines for displaying manual pages online. * also removes the page headers and footers in the middle of the manual. * a replacement for the one which comes with SCO's manual page package * because that one dumps core. This one also accepts filename args. */ static char rcsid[] = "@(#) $Header: /home/ronald/rmb.c,v 1.2 1991/05/10 20:28:16 ronald Exp $"; static char authorinfo[] = "@(#) Ronald Khoo <ronald@ibmpcug.co.uk>"; #include <ctype.h> #include <stdlib.h> #include <stdio.h> #include <string.h> char *prog; /* No, I don't cope with arbitrarily long input. The first version of this program did, but it spent too much time in malloc/free, so here's a few fixed buffers instead. I know it can be done properly, but it's not worth it. */ #define MAXLEN 4096 char line1[MAXLEN], line2[MAXLEN], nukeline[MAXLEN]; /* buffer a line for output, with ability to undo the outputting of previous line if handed a NULL. Always returns an available buffer to use, unless there was an output error in which case NULL is returned. The argument may only be line1, line2 or NULL. */ int before, after, gotone; #define CLRET(x) { gotone = before = after = 0; return (x); } char * outputline(s) char *s; { char *other; if (s == 0) { gotone = after = 0; before = 1; return line1; } if (s == line1) other = line2; else if (s == line2) other = line1; else CLRET(line1) if (*s == '\n') { after++; return; } if (gotone) { for (; before; before--) if (putchar('\n') != '\n') CLRET(0) if (fputs(other, stdout) == EOF) CLRET(0) before = after; after = 0; } gotone = 1; return other; } /* copy t to s, deleting .^H nroff bullshit */ void nukebscpy(s, t) register char *s, *t; { register char c; while (*t && *t == '\b') t++; while (c = (*s++ = *t++)) if (c == '\b') *(s-=2) = 0; } /* return true if s matches foo(n).*foo(n) like manual pages do. */ int /* boolean */ isheader(s) char *s; { int len, found; char *p, *q; nukebscpy(nukeline, s); s = nukeline; while (*s && isspace(*s)) s++; if ((p = strchr(s, ')')) == 0 || p[1] == 0) return 0; found = 0; for (q = s; q < p; q++) { if (isspace(*q)) return 0; if (*q == '(') found = 1; } if (found == 0) return 0; /* s -> head of title, p -> ending ')' */ len = p - s + 1; if ((q = strrchr(p+1, ')')) == 0) return 0; if (q - p < len) return 0; /* second copy of the header must be at the end of the line */ if (q[1] != '\n') return 0; if (strncmp(s, q + 1 - len, len) == 0) { return 1; } return 0; } #define MAXBLANKS 1 void rmb(fp) FILE *fp; { register char *strend; int blanks = MAXBLANKS; /* delete blanks at the top too */ int donehdr = 0; char *s = line1; while (fgets(s, MAXLEN, fp)) { if (strend = strchr(s, '\n')) { while (strend > s && isspace(*--strend)) { strend[0] = '\n'; strend[1] = 0; } } if (blanks == MAXBLANKS) { if (isheader(s)) { if (donehdr) { if ((s = outputline((char *)0)) == 0) { fprintf(stderr, "%s: write error on output\n", prog); s = line1; } continue; } donehdr = 1; } } if (*s == '\n') { if (blanks == MAXBLANKS) { continue; } else blanks++; } else blanks = 0; donehdr = 1; /* pretend we've already seen a header because SCO Unix manuals seem to delete the first header sometimes. Sigh */ if ((s = outputline(s)) == 0) { fprintf(stderr, "%s: write error on output\n", prog); s = line1; } } *s = 0; if (outputline(s) == 0) fprintf(stderr, "%s: write error on output\n", prog); } int main(argc, argv) int argc; char **argv; { FILE *fp; prog = argc > 0? argv[0]: "rmb"; if (argc < 2) rmb(stdin); else { if ((fp = fopen(*++argv, "r")) == 0) { fprintf(stderr, "%s: cannot open %s\n", prog, *argv); } else { rmb(fp); if (fclose(fp) == EOF) { fprintf(stderr, "%s: %s: error on fclose\n", prog, *argv); } } } } -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
clewis@ferret.ocunix.on.ca (Chris Lewis) (06/21/91)
In article <9106192118.AA27899@robobar.Co.Uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: Hi Ronald! >Michael John Staley <staley@lad.med.utas.edu.au> wrote: >> [About SCO Text processing package on SCO UNIX] >> I found that the its use was VERY limited in that I could >> not do things like eqn, tbl etc. [There seems to be a thread of confusion here w.r.t. troff vs. nroff] >I have used the eqn and tbl from the XENIX text processing system under >SCO UNIX with reasonably good results, using psroff 2.0. >Can you explain just why you can't use tbl and eqn? I can. To clarify: 1) nroff *does* work with tbl (but you have to pipe the output of nroff thru col to avoid scrambulation due to reverse line feeds). I imagine you also have neqn which attempts to take nroff's limitations into account and give you a "reasonable" representation of eqn. 2) Psroff (1.0, 2.0, 3.0) works with C/A/T *troff*, not nroff. C/A/T Troff is also part of the Xenix Text Processing Package. And Xenix's troff and psroff work together quite well. Quite a number of people are using Xenix's C/A/T troff with psroff without any trouble on postscript and HP Laserjet printers. (Psroff 3.0 also works with ditroff aka DWB, and even groff if you need good HP Laserjet output) >> My problems have increased recently as I have imported psroff 3.0 which >> requires a GOOD version of nsroff. >Actually PSROFF wants troff. The SCO troff is "good enough". >It's a bit buggy, but not seriously so -- I used it for several years, >first with the "thack" postscript driver, then psroff 1.0, then psroff 2.0. >I'm still waiting for Rich Salz to post 3.0... :-) As far as I'm aware, SCO's troff is no worse than any other C/A/T troff. There was a rumor (back in psroff 1.0 days) that there was something odd about Xenix Troff's offset and pagelength, but I was unable to confirm precisely what the problem was. >> Where can I obtain a good version >> of nroff which has all the bits and which will run with SCO Unix and >> my new psroff 3.0. I think you already have all the bits. *Except* pic and grap. If you need to run pic (line drawing) or grap, I suggest you get groff as Ronald has suggested. Psroff does a very good job with C/A/T troff, and as long as you don't have to do much in the way of line drawing, need kerning, or go totally bonkers with fonts (C/A/T troff has some limitations on number of fonts available per line), psroff will do what you want, faster than groff. >Well, you can drop the SCO troff and psroff completely, and get GNU troff >instead (you will want to retain the ms and mm macro packages from >the text processing system -- /usr/lib/tmac and /usr/lib/macros) Does groff support mm now? -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
ronald@robobar.co.uk (Ronald S H Khoo) (06/21/91)
Chris Lewis <clewis@ferret.ocunix.on.ca> wrote: > Hi Ronald! Hi Chris! Ain't these mailing-list->news gateways annoying ? All the news-specific headers seem to get munged. But see the discussion in news.software.{b,nntp} about that ... :-) > [There seems to be a thread of confusion here w.r.t. troff vs. nroff] You're right. But why anyone would want to use nroff to drive his HPLJIII I can't understand. Now, if we could only get decent graphics cost down, we could chuck nroff altogether and tell man(1) to use Xditview instead of col | more...... > I imagine you also have neqn $ grep neqn /etc/perms/* EQN x711 bin/bin 1 ./usr/bin/neqn T01 HELP f644 bin/bin 1 ./usr/lib/help/neqn T01 Yup. > C/A/T Troff is also part of the Xenix Text Processing Package. $ troff Typesetter busy. Yup. > and even groff if you need good HP Laserjet output H'm. Maybe I ought to quit waiting on c.s.u and get FTPing then :-) No nice LaserJet II fonts though :-( Times ain't too hot on lasers. I tend to use the PostScript builtin Palatino -- it's thicker than Times, therefore comes out a lot nicer, especially if you're about to photocopy. The HP fonts that I do have don't include anything similar. Sigh. > As far as I'm aware, SCO's troff is no worse than any other C/A/T troff. Well, there's the bug with conditionals that upsets -me. The nice thing about groff is that James Clark tends to fix macro packages and so you get a modified -me and -mdoc with groff -- damned useful if you want to print Berzerkeley manuals. SCO's troff doesn't like -mdoc at all. I spent several days hacking at the macros to get useable output, and ended up hacking the output postscript as well. Now I use groff for that stuff and take the performance hit. So, yes, SCO's troff is older and buggier than the BSD one, so don't expect it to cope with everything. > There was a rumor (back in psroff 1.0 days) that there was something > odd about Xenix Troff's offset and pagelength, but I was unable to > confirm precisely what the problem was. Can't tell you. Seeing that I use A4 anyway, I always have problems with that kind of thing in any case. Especially when I'm actually doing 2-up to use up those SCO manual binders which really prefer different page offsets on odd and even pages ... :-) > I think you already have all the bits. *Except* pic and grap. If you > need to run pic (line drawing) or grap, I suggest you get groff as > Ronald has suggested. No grap with groff. But the pic is good. > psroff will do what you want, faster than groff. Very much faster, especially if, like me, you don't have a floating point unit. > Does groff support mm now? Yes. James Clark distributes a patch and an edit script with groff. SCO's -mm is old and slightly buggy, though. I guess it's not advisable to start new projects in -mm. It's dead slow anyhow. Between James Clark and Chris Lewis, I think troff's life has been extended beyond expectation. I have been afraid of TeX taking over, but I think troff will continue, thanks to the efforts of these two kind gentlemen, not forgetting the cast of thousands behind the scenes, of whom I think Ron Florence deserves a special mention for his contribution to psroff's Laserjet support. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
npn@cbnewsl.att.com (nils-peter.nelson) (06/25/91)
Somewhere in the middle of this article the subject of man under X came up. I've seen several (to me) over- engineered versions that take thousands of lines of code to turn nroff output back into variable width, including handling overstrikes, underlines, etc. Herewith my own 3 line version of man for X windows; it relies on the fact that DWB 3.2 -man macros offer compatibility with all known implementations (actually, all the ones we bothered to find), and on xtv, which is a working version of xditview. The first line pumps the point size up, 'cause I'm finally at the age where I have trouble reading 10 point type. === echo '.nr )S 12 .po +2' | \ troff -man - `whence $1 | sed "s:[^/]*/$1:man/man1/$1.1:"` | xtv & === Also, an editorial comment to: Between James Clark and Chris Lewis, I think troff's life has been extended beyond expectation. === To wit: (pout, pout) At least Brian Kernighan should be mentioned.