* Re: [TUHS] roff(7)
@ 2021-12-31 15:47 Douglas McIlroy
2021-12-31 23:07 ` George Michaelson
0 siblings, 1 reply; 102+ messages in thread
From: Douglas McIlroy @ 2021-12-31 15:47 UTC (permalink / raw)
To: TUHS main list
> Did roff do all of what troff and nroff did?
No way. Ossanna deserves all the praise you give him. Roff extended
runoff in various ways:
relative numeric operators, e.g. .in +8
tabbing (left, right and centered)
underlining
tripartite headers and footers
arabic and roman page numbering
adjustable head and foot margins
automatic hyphenation, thanks to Molly Wagner
footnotes
merge patterns for change marks, column separators, etc.
various special requests: .ne, .ti, .tr, .po, .op (odd page)
But roff did NOT have conditionals, traps, special characters,
environments, or arbitrary motion control. Crucially (and ironically,
because I was Mr. Macro), it did not have anything like macros,
strings and diversions until after Joe pioneered them in nroff.
So there was a gaping disparity: nroff was Turing complete, roff
wasn't. Roff merely added features to runoff; nroff leapt into a
different universe.
-----------------------
The features listed above are in the January 1971 manual for BCPL
roff, which is probably the anonymous reference cited in the November
1971 v1 manual. The v1 manual lists Osanna, Ken and Dennis as authors
of the Unix implementation. I believe Ossanna is named because he
added line-numbering--and maybe more--to entice the patent department
to switch to roff.
BCPL roff allowed all four arithmetic operators in contexts like .ls
*3. Only + and - were allowed in nroff. Eventually both BCPL roff and
nroff got number registers (defined by different commands); I don't
recall which came first. BCPL roff also got a weak macro facility,
definitely after nroff.
Doug
^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2021-12-31 15:47 [TUHS] roff(7) Douglas McIlroy @ 2021-12-31 23:07 ` George Michaelson 2021-12-31 23:40 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 102+ messages in thread From: George Michaelson @ 2021-12-31 23:07 UTC (permalink / raw) To: Douglas McIlroy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2401 bytes --] In 79-82 Runoff got me my undergraduate texts formatted on a dec10. Moving to work post degree on Unix and vms systems (my memory is that for some reason VMS didn't have runoff) I had the Normalised "oh this must be the same" hitting roff/nroff and got really confused by having both ms and me macros. Nobody seemed to be able to explain to me why you wanted both (the mysteries and distinctions of v<X> vs BSD were completely lost to me at this early stage). But macros aside, anyone who had used runoff had a massively simpler path into roff than TeX. My future was set. The phd students at Leeds looked down their noses at me for using cryptic .2 letter inline magic. They were the high priests of things, I was just a computer operator. Watching them spend weeks and weeks wrangling a one em offset problem stopping perfection in print was.. entertaining. Then we somehow got ditroff at Leeds uni. That was really weird, because it was obviously "better" but again nobody could explain why the di- bit magically appeared. (We had a Benson- Varian slimey paper printer at some fantastical dpi like 120 or 150 which turned up at the same time.) wasn't this just Troff? Oh God, was it really called t/roff not troff... The entire production path to lpr had some driver logic to put "--" cut marks on the continuous paper so you knew where to guillotine from the roll, but unfortunately was wired to US legal paper sizes not A4 (presumably some macro definitions file would have fixed this) I still have a poem from the British computer society about the birth of the icl 2900 typeset in olde English, centred. That Benson-Varian must have used damn good printing because it's still readable 40 years later when parking tickets (similar print process?) Fade out in a day. It was also around the time that "tbl" had what we all thought was a bug, drawing the horizontal boxlines off by one. Nobody at the time understood this was to counteract a specific electromechanical printer issue inside AT&T. Since it was coming in BSD Unix I can imagine back inside Berkeley people binning our complaints. If you don't remember which 1200bpi tape the software came from, don't just complain at random... The "pic" tool had also just hit, and it obviously didn't share those line offset problems which made us all very suspicious: "ITS THE SAME PEOPLES CODE" we shouted at each other (it wasnt) ... G [-- Attachment #2: Type: text/html, Size: 2871 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2021-12-31 23:07 ` George Michaelson @ 2021-12-31 23:40 ` Larry McVoy 2022-01-01 0:56 ` [TUHS] TeX and groff (was: roff(7)) Greg 'groggy' Lehey 2022-01-01 20:00 ` [TUHS] roff(7) [ and other related stuff ] Jon Steinhart 2022-01-01 1:11 ` [TUHS] roff(7) Phil Budne 2022-01-05 21:15 ` Tony Finch 2 siblings, 2 replies; 102+ messages in thread From: Larry McVoy @ 2021-12-31 23:40 UTC (permalink / raw) To: George Michaelson; +Cc: TUHS main list, Douglas McIlroy On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: > But macros aside, anyone who had used runoff had a > massively simpler path into roff than TeX. My future was set. The phd > students at Leeds looked down their noses at me for using cryptic .2 letter > inline magic. They were the high priests of things, I was just a computer > operator. Watching them spend weeks and weeks wrangling a one em offset > problem stopping perfection in print was.. entertaining. I was program committee chair for Linux Expo in 1999 (all that means is I formatted the proceedings into a book). I let people use LaTex but encouraged troff. A few people tried out troff and their reaction was "Wow, that was so easy and groff is really fast!" The only negative reaction was table of contents complaints, LaTex is 2 pass so it can do them, roff is one pass so you have to fiddle with things. A lot. I've used *roff for almost 40 years and I've never had the urge to use something else. I wrote a paper a while back where they insisted on LaTex and it just made me like *roff more. It's Betamax and VHS all over again, the crappy answer won. --lm ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] TeX and groff (was: roff(7)) 2021-12-31 23:40 ` Larry McVoy @ 2022-01-01 0:56 ` Greg 'groggy' Lehey 2022-01-01 3:15 ` Larry McVoy 2022-01-01 20:00 ` [TUHS] roff(7) [ and other related stuff ] Jon Steinhart 1 sibling, 1 reply; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-01 0:56 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 2861 bytes --] On Friday, 31 December 2021 at 15:40:39 -0800, Larry McVoy wrote: > On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: >> But macros aside, anyone who had used runoff had a >> massively simpler path into roff than TeX. My future was set. The phd >> students at Leeds looked down their noses at me for using cryptic .2 letter >> inline magic. They were the high priests of things, I was just a computer >> operator. Watching them spend weeks and weeks wrangling a one em offset >> problem stopping perfection in print was.. entertaining. > > I was program committee chair for Linux Expo in 1999 (all that means is > I formatted the proceedings into a book). I let people use LaTex but > encouraged troff. A few people tried out troff and their reaction was > "Wow, that was so easy and groff is really fast!" Heh. I had a similar experience when writing "Porting Unix Software" (1995). O'Reilly insisted on using groff with their macro set, and I had only had experience with (La)TeX. I fought for quite some time, but ultimately gave in. Despite Baby Duck Syndrome, I discovered that I far preferred groff to TeX, and I've been using it ever since. From PUS: .Pe More than anywhere else in porting, it is good for your state of mind to steer clear of .TXI \& internals. The assumptions on which the syntax is based differ markedly from those of other programming languages. For example, identifiers may not contain digits, and spaces are required only when the meaning would otherwise be ambiguous (to .TXI , not to you), so the sequence \s10\f(CWfontsize300\fR\s0 is in fact the identifier \s10\f(CWfontsize\fR\s0 followed by the number \s10\f(CW300\fR\s0. On the other hand, it is almost impossible to find any good solid information in the documentation, so you could spend hours trying to solve a minor problem. I have been using .TXI \& frequently for years, and I still find it the most frustrating program I have ever seen.\** .FS When I wrote this sentence, I wondered if I wasn't overstating the case. Mike Loukides, the author of \fIProgramming with GNU Software\fR, reviewed the final draft and added a single word: \fIAmen\fR. .FE > The only negative reaction was table of contents complaints, LaTex is > 2 pass so it can do them, roff is one pass so you have to fiddle with > things. A lot. I solved that issue in later documents with two passes in the Makefile targets, frobbing things like references and contents in between. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-01 0:56 ` [TUHS] TeX and groff (was: roff(7)) Greg 'groggy' Lehey @ 2022-01-01 3:15 ` Larry McVoy 2022-01-10 19:00 ` Blake McBride 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-01 3:15 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list, Douglas McIlroy On Sat, Jan 01, 2022 at 11:56:05AM +1100, Greg 'groggy' Lehey wrote: > > The only negative reaction was table of contents complaints, LaTex is > > 2 pass so it can do them, roff is one pass so you have to fiddle with > > things. A lot. > > I solved that issue in later documents with two passes in the Makefile > targets, frobbing things like references and contents in between. I was troff friends with W Richard Stevens, he shared with me a lot of what he did in troff. He did the two pass thing. Nice guy and got as much out of roff that anyone could, all of his books were troff. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-01 3:15 ` Larry McVoy @ 2022-01-10 19:00 ` Blake McBride 2022-01-10 20:21 ` Jon Forrest ` (3 more replies) 0 siblings, 4 replies; 102+ messages in thread From: Blake McBride @ 2022-01-10 19:00 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 2962 bytes --] I've used nroff/troff/TeX with many of their various macro packages over about a 35 years span. During that time, I've done many single-page documents as well as documents as long as 350 pages. I also modified a version of nroff to create business forms for Laster printers. This is still being used commercially. This is one person's opinion: 1. Perhaps owing to my limited intelligence, and in spite of the fact that I've used TeX successfully on many documents, I have never been able to fully understand TeX. Apparently, it is too much for me. Troff, on the other hand, has made full sense to me. I was able to make it do what I wanted almost always. I enjoy using troff more because I find it simpler, and therefore, more pleasant to use. 2. Looking at the output, it is my opinion that TeX produces better-looking documents. Perhaps this is just no more than one man's esthetic opinion. I do not know what it is that I find better. It's just the sense I get. On the other hand, I find troff output to be sufficiently good in nearly all cases. 3. troff is a good and reasonable tool. TeX is too big and complex an environment in most cases. Although it is true that all of the complexity of the TeX environment is successfully hidden in virtually all cases. I find the huge and complex environment offputting. Very unfortunately, I see troff disappearing. I've worked with a number of teams over the last ten years. In every case, I was the oldest engineer. Also, in each case, I was the only engineer who had even heard of troff. They understand the problems of binary formats such as Word and OpenOffice. Their solutions are things like markdown, AsciiDoc, et al. They are doing this development and making use of these tools without knowledge of troff. The same is true to a greater or lesser degree with TeX, except that I've seen TeX used at universities. I like that groff and TeX are rock solid and well supported. In fact, I wrote a report generator for a modern web development framework using troff. I use it to develop reports on a routine basis. (kissweb.org) Sadly, however, if word of their existence doesn't get out there, I see them both disappearing in not much longer than a generation. This would be sad indeed. Blake McBride On Fri, Dec 31, 2021 at 9:16 PM Larry McVoy <lm@mcvoy.com> wrote: > On Sat, Jan 01, 2022 at 11:56:05AM +1100, Greg 'groggy' Lehey wrote: > > > The only negative reaction was table of contents complaints, LaTex is > > > 2 pass so it can do them, roff is one pass so you have to fiddle with > > > things. A lot. > > > > I solved that issue in later documents with two passes in the Makefile > > targets, frobbing things like references and contents in between. > > I was troff friends with W Richard Stevens, he shared with me a lot of > what he did in troff. He did the two pass thing. Nice guy and got as > much out of roff that anyone could, all of his books were troff. > [-- Attachment #2: Type: text/html, Size: 3622 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 19:00 ` Blake McBride @ 2022-01-10 20:21 ` Jon Forrest 2022-01-11 22:48 ` Blake McBride 2022-01-10 20:33 ` Larry McVoy ` (2 subsequent siblings) 3 siblings, 1 reply; 102+ messages in thread From: Jon Forrest @ 2022-01-10 20:21 UTC (permalink / raw) To: tuhs On 1/10/22 11:00 AM, Blake McBride wrote: > I like that groff and TeX are rock solid and well supported. > Sadly, however, if word of their existence doesn't get out there, I see > them both disappearing in not much longer than a generation. This would > be sad indeed. TeX badly need an official rewrite in a modern programming language (e.g. Go, Rust, even C). The rewrite should drop support for the .dvi format, and use .pdf instead. It should also make use of modern hardware capabilities and not have any built-in limits to how much memory gets used. These issues are well recognized by the TeX community but with Knuth not willing to be the BDFL, TeX is floundering. (I don't mean any of this as criticism of TeX. It's a truly miraculous program that was created in a different time.) Jon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 20:21 ` Jon Forrest @ 2022-01-11 22:48 ` Blake McBride 2022-01-11 23:18 ` Larry McVoy ` (3 more replies) 0 siblings, 4 replies; 102+ messages in thread From: Blake McBride @ 2022-01-11 22:48 UTC (permalink / raw) To: Jon Forrest; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2163 bytes --] On Mon, Jan 10, 2022 at 2:22 PM Jon Forrest <nobozo@gmail.com> wrote: > > TeX badly need an official rewrite in a modern programming language > (e.g. Go, Rust, even C). The rewrite should drop support for the > .dvi format, and use .pdf instead. It should also make use of > modern hardware capabilities and not have any built-in limits > to how much memory gets used. > > These issues are well recognized by the TeX community but with > Knuth not willing to be the BDFL, TeX is floundering. > > (I don't mean any of this as criticism of TeX. It's a truly > miraculous program that was created in a different time.) > > Jon > > Although I'm not connected with the TeX community, I don't agree with much of what you said. 1. TeX source to C is fine - stable and works. It would be impossible to rewrite TeX in any other language without introducing bugs and incompatibilities. Leaving TeX as-is means that it can be converted to other languages too if/when C goes out of style. TeX as-is is exactly what it is. Anything else wouldn't be TeX. 2. Drop DVI? Are you kidding me? Although PDF may be popular now, that may not be the case 20 years from now. A device-independent format is what is needed, and that's what DVI is. TeX is guaranteed to produce the exact same output 100 years from now. 3. I am curious about memory limitations within TeX. 4. Knuth is getting up in age. Someone will have to take over. I suppose #4 was my whole point about both TeX and troff. They're both great tools. Perhaps people used them in the past because there weren't many other solutions. You had to learn them. These days people prefer the simpler tools such as Word, OpenOffice, etc. Although they can't produce the same quality, they can produce sufficient quality with a smaller learning curve. Don't get me wrong, I despise Word. I just don't find my feelings echoed very much. Some things TeX and troff are going to need in order to continue: 1. Continue to be maintained 2. An effort to make knowledge of them wider will have to occur if they are to continue. 3. A case for their benefit will have to be made and dispersed. Blake McBride [-- Attachment #2: Type: text/html, Size: 2881 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 22:48 ` Blake McBride @ 2022-01-11 23:18 ` Larry McVoy 2022-01-12 1:19 ` Dave Horsfall ` (2 more replies) 2022-01-12 0:06 ` Jon Steinhart ` (2 subsequent siblings) 3 siblings, 3 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-11 23:18 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > Some things TeX and troff are going to need in > order to continue: > > 1. Continue to be maintained > > 2. An effort to make knowledge of them wider will have to occur if they > are to continue. > > 3. A case for their benefit will have to be made and dispersed. Well, someone could do what I tried (and failed) to do: make Word produce high quality eqn/tbl/pic/troff source as their internal format. There was such a thing for TeX, can't remember the name, but my Dad (very computer not savvy) used it to write a book. It was WYSIWYG but spit out TeX. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 23:18 ` Larry McVoy @ 2022-01-12 1:19 ` Dave Horsfall 2022-01-12 1:46 ` Blake McBride 2022-01-12 2:12 ` Bakul Shah 2 siblings, 0 replies; 102+ messages in thread From: Dave Horsfall @ 2022-01-12 1:19 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 11 Jan 2022, Larry McVoy wrote: > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal format. I doubt whether that will ever happen; M$ like to keep their internal format proprietary (and apparently change it with each release) to keep third-parties out. -- Dave ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 23:18 ` Larry McVoy 2022-01-12 1:19 ` Dave Horsfall @ 2022-01-12 1:46 ` Blake McBride 2022-01-12 2:12 ` Bakul Shah 2 siblings, 0 replies; 102+ messages in thread From: Blake McBride @ 2022-01-12 1:46 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 746 bytes --] On Tue, Jan 11, 2022 at 5:18 PM Larry McVoy <lm@mcvoy.com> wrote: > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > > 3. A case for their benefit will have to be made and dispersed. > > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal > format. > As I said earlier, I despise Word for many reasons. I think making Word, or any proprietary software, do anything as, in the long haul, a waste of time. > > There was such a thing for TeX, can't remember the name, but my > Dad (very computer not savvy) used it to write a book. It was > WYSIWYG but spit out TeX. > Probably LyX <https://www.lyx.org/>. I use it frequently. Blake McBride [-- Attachment #2: Type: text/html, Size: 1321 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 23:18 ` Larry McVoy 2022-01-12 1:19 ` Dave Horsfall 2022-01-12 1:46 ` Blake McBride @ 2022-01-12 2:12 ` Bakul Shah 2022-01-12 15:49 ` Larry McVoy 2 siblings, 1 reply; 102+ messages in thread From: Bakul Shah @ 2022-01-12 2:12 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list > On Jan 11, 2022, at 3:18 PM, Larry McVoy <lm@mcvoy.com> wrote: > > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: >> Some things TeX and troff are going to need in >> order to continue: >> >> 1. Continue to be maintained >> >> 2. An effort to make knowledge of them wider will have to occur if they >> are to continue. >> >> 3. A case for their benefit will have to be made and dispersed. > > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal > format. > > There was such a thing for TeX, can't remember the name, but my > Dad (very computer not savvy) used it to write a book. It was > WYSIWYG but spit out TeX. May be Textures by Blue Sky Research? ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 2:12 ` Bakul Shah @ 2022-01-12 15:49 ` Larry McVoy 2022-01-12 16:22 ` Adam Thornton 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-12 15:49 UTC (permalink / raw) To: Bakul Shah; +Cc: TUHS main list On Tue, Jan 11, 2022 at 06:12:45PM -0800, Bakul Shah wrote: > > > > On Jan 11, 2022, at 3:18 PM, Larry McVoy <lm@mcvoy.com> wrote: > > > > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > >> Some things TeX and troff are going to need in > >> order to continue: > >> > >> 1. Continue to be maintained > >> > >> 2. An effort to make knowledge of them wider will have to occur if they > >> are to continue. > >> > >> 3. A case for their benefit will have to be made and dispersed. > > > > Well, someone could do what I tried (and failed) to do: make Word > > produce high quality eqn/tbl/pic/troff source as their internal > > format. > > > > There was such a thing for TeX, can't remember the name, but my > > Dad (very computer not savvy) used it to write a book. It was > > WYSIWYG but spit out TeX. > > May be Textures by Blue Sky Research? That's it. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 15:49 ` Larry McVoy @ 2022-01-12 16:22 ` Adam Thornton 0 siblings, 0 replies; 102+ messages in thread From: Adam Thornton @ 2022-01-12 16:22 UTC (permalink / raw) To: Larry McVoy; +Cc: Bakul Shah, TUHS main list > On Jan 12, 2022, at 8:49 AM, Larry McVoy <lm@mcvoy.com> wrote: > > On Tue, Jan 11, 2022 at 06:12:45PM -0800, Bakul Shah wrote: >> >> >>> On Jan 11, 2022, at 3:18 PM, Larry McVoy <lm@mcvoy.com> wrote: >>> >>> There was such a thing for TeX, can't remember the name, but my >>> Dad (very computer not savvy) used it to write a book. It was >>> WYSIWYG but spit out TeX. >> >> May be Textures by Blue Sky Research? > > That's it. LyX is a venerable and not entirely unsuccessful attempt to put a WYSIWYG front end on LaTeX. Every few years I try to use it and then go back to something else. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 22:48 ` Blake McBride 2022-01-11 23:18 ` Larry McVoy @ 2022-01-12 0:06 ` Jon Steinhart 2022-01-12 1:48 ` Blake McBride 2022-01-12 0:29 ` Nemo Nusquam [not found] ` <E3CC4B8A-4E88-4339-A4D3-4ED26BA80620@gmail.com> 3 siblings, 1 reply; 102+ messages in thread From: Jon Steinhart @ 2022-01-12 0:06 UTC (permalink / raw) To: TUHS main list Blake McBride writes: > I suppose #4 was my whole point about both TeX and troff. They're both > great tools. Perhaps people used them in the past because there weren't > many other solutions. You had to learn them. These days people prefer the > simpler tools such as Word, OpenOffice, etc. Although they can't produce > the same quality, they can produce sufficient quality with a smaller > learning curve. Don't get me wrong, I despise Word. I just don't find my > feelings echoed very much. Some things TeX and troff are going to need in > order to continue: I disagree with your characterization that things like Word are simpler tools. They're way more complex than troff or TeX, both in code and usability. FYI, last time I saw Don he was asked what his biggest mistake ever was. His response was making the basic unit size in TeX a power of 2 instead of a power of 10. While I'm at it, a shill also asked him what his favorite joke was. His answer: A guy goes into the county clerk and asks to legally change his name. The clerk asks "What would you like to change it to?" The guy responds "Control G". The clerk says "That rings a bell." ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 0:06 ` Jon Steinhart @ 2022-01-12 1:48 ` Blake McBride 0 siblings, 0 replies; 102+ messages in thread From: Blake McBride @ 2022-01-12 1:48 UTC (permalink / raw) To: Jon Steinhart; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 873 bytes --] On Tue, Jan 11, 2022 at 6:07 PM Jon Steinhart <jon@fourwinds.com> wrote: > Blake McBride writes: > > I suppose #4 was my whole point about both TeX and troff. They're both > > great tools. Perhaps people used them in the past because there weren't > > many other solutions. You had to learn them. These days people prefer > the > > simpler tools such as Word, OpenOffice, etc. Although they can't produce > > the same quality, they can produce sufficient quality with a smaller > > learning curve. Don't get me wrong, I despise Word. I just don't find > my > > feelings echoed very much. Some things TeX and troff are going to need > in > > order to continue: > > I disagree with your characterization that things like Word are simpler > tools. > They're way more complex than troff or TeX, both in code and usability. > We'll have to agree to disagree. --blake [-- Attachment #2: Type: text/html, Size: 1323 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 22:48 ` Blake McBride 2022-01-11 23:18 ` Larry McVoy 2022-01-12 0:06 ` Jon Steinhart @ 2022-01-12 0:29 ` Nemo Nusquam 2022-01-12 1:53 ` Blake McBride [not found] ` <E3CC4B8A-4E88-4339-A4D3-4ED26BA80620@gmail.com> 3 siblings, 1 reply; 102+ messages in thread From: Nemo Nusquam @ 2022-01-12 0:29 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/html, Size: 788 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 0:29 ` Nemo Nusquam @ 2022-01-12 1:53 ` Blake McBride 0 siblings, 0 replies; 102+ messages in thread From: Blake McBride @ 2022-01-12 1:53 UTC (permalink / raw) To: Nemo Nusquam; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 435 bytes --] On Tue, Jan 11, 2022 at 6:30 PM Nemo Nusquam <cym224@gmail.com> wrote: > On 2022-01-11 17:48, Blake McBride wrote (in part): > > > 4. Knuth is getting up in age. Someone will have to take over. > > > Someone has: https://www.latex-project.org/latex3/ > Although that page talks about LaTeX (a macro package) a lot, it doesn't mention support for TeX (the actual processor). Tex is like troff LaTeX is like mm or ms Blake McBride [-- Attachment #2: Type: text/html, Size: 2158 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <E3CC4B8A-4E88-4339-A4D3-4ED26BA80620@gmail.com>]
* Re: [TUHS] TeX and groff (was: roff(7)) [not found] ` <E3CC4B8A-4E88-4339-A4D3-4ED26BA80620@gmail.com> @ 2022-01-12 0:44 ` Jon Forrest 2022-01-12 2:00 ` Blake McBride 0 siblings, 1 reply; 102+ messages in thread From: Jon Forrest @ 2022-01-12 0:44 UTC (permalink / raw) To: tuhs This is clearly getting off track of TUHS. I'll stop after this reply. > *From:* Blake McBride <blake1024@gmail.com> > *Date:* January 11, 2022 at 2:48:23 PM PST > *To:* Jon Forrest <nobozo@gmail.com> > *Cc:* TUHS main list <tuhs@minnie.tuhs.org> > *Subject:* *[TUHS] TeX and groff (was: roff(7))* > Although I'm not connected with the TeX community, I don't agree with > much of what you said. > > 1. TeX source to C is fine - stable and works. It would be > impossible to rewrite TeX in any other language without introducing > bugs and incompatibilities. Leaving TeX as-is means that it can be > converted to other languages too if/when C goes out of style. TeX > as-is is exactly what it is. Anything else wouldn't be TeX. I agree that Web->C works but it's a major obstacle in doing any development work on TeX. Try making a major change in the Web source that requires debugging. Anything that can pass the TeX Trip Test can be called TeX. I know of a full C reimplementation that passes the test but the author doesn't want to make it free software. There are other rewrites out there that could be candidates but someone will enough power will have to proclaim one as the official TeX alternative. > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, > that may not be the case 20 years from now. A device-independent > format is what is needed, and that's what DVI is. TeX is guaranteed > to produce the exact same output 100 years from now. And .PDF isn't? .DVI was great until .PDF matured. .DVI has almost no penetration these days, whereas .PDF is everywhere. I'm not saying that .PDF will always be the proper alternative but a properly rewritten TeX should make it much easier to replace .PDF will whatever comes next. > 3. I am curious about memory limitations within TeX. TeX has various fixed sized memory pools, and contains clever code to work around limited memory. Some of the newer TeXs, like LuaTeX, use dynamic allocation but this isn't official. Given how primitive things were when TeX was developed it's a miracle it works as well as it does. > 4. Knuth is getting up in age. Someone will have to take over. Exactly. I don't follow the TeX community so I don't know what they're doing about this. Jon Forrest ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 0:44 ` Jon Forrest @ 2022-01-12 2:00 ` Blake McBride 2022-01-12 2:10 ` David Arnold 2022-01-12 19:54 ` John Cowan 0 siblings, 2 replies; 102+ messages in thread From: Blake McBride @ 2022-01-12 2:00 UTC (permalink / raw) To: Jon Forrest; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1461 bytes --] On Tue, Jan 11, 2022 at 6:45 PM Jon Forrest <nobozo@gmail.com> wrote: > I know of > a full C reimplementation that passes the test but the author doesn't > want to make it free software. > Although it is possible, I find this hard to believe. I can't imagine spending as much time as would be required to duplicate something that already exists. > > There are other rewrites out there that could be candidates but someone > will enough power will have to proclaim one as the official TeX > alternative. > Again, hard to believe. > > > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, > > that may not be the case 20 years from now. A device-independent > > format is what is needed, and that's what DVI is. TeX is guaranteed > > to produce the exact same output 100 years from now. > > And .PDF isn't? > No. It isn't. It is an Adobe product. > > .DVI was great until .PDF matured. .DVI has almost no penetration > these days, whereas .PDF is everywhere. DVI was never meant to have any penetration. It was always intended to be an intermediary format. > I'm not saying that .PDF > will always be the proper alternative but a properly rewritten TeX > should make it much easier to replace .PDF will whatever comes > next. > Again, given the complexity of a proper TeX, and its declining popularity, I find it ver hard to believe that someone would spend the time to duplicate, with enhancements, it. Blake McBride [-- Attachment #2: Type: text/html, Size: 2568 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 2:00 ` Blake McBride @ 2022-01-12 2:10 ` David Arnold 2022-01-12 2:26 ` Adam Thornton 2022-01-12 19:54 ` John Cowan 1 sibling, 1 reply; 102+ messages in thread From: David Arnold @ 2022-01-12 2:10 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 532 bytes --] <…> >> > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> >> And .PDF isn't? > > No. It isn't. It is an Adobe product. Check out ISO 32000-2:2020. I think it’s ok in 2022 to say that PDF has escaped Adobe and is an open standard, suitable for long-life documents, etc. d [-- Attachment #2: Type: text/html, Size: 1120 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 2:10 ` David Arnold @ 2022-01-12 2:26 ` Adam Thornton 0 siblings, 0 replies; 102+ messages in thread From: Adam Thornton @ 2022-01-12 2:26 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1086 bytes --] Knuth made an excellent point, maybe in _Coders At Work_ about literate programming and why it didn't catch on: in general, about 1 out of 20 people can be a really good programmer. In general, one of 20 people can be a really good writer. These talents are largely uncorrelated. Sure, being competent at either is a teachable skill. But no one wants to read either a program or a narrative written by someone who's merely OK at it. Adam On Tue, Jan 11, 2022 at 7:20 PM David Arnold <davida@pobox.com> wrote: > <…> > > > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> >> And .PDF isn't? >> > > No. It isn't. It is an Adobe product. > > > Check out ISO 32000-2:2020. > > I think it’s ok in 2022 to say that PDF has escaped Adobe and is an open > standard, suitable for long-life documents, etc. > > > > d > [-- Attachment #2: Type: text/html, Size: 1855 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 2:00 ` Blake McBride 2022-01-12 2:10 ` David Arnold @ 2022-01-12 19:54 ` John Cowan 2022-01-13 10:13 ` Thomas Paulsen 1 sibling, 1 reply; 102+ messages in thread From: John Cowan @ 2022-01-12 19:54 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1406 bytes --] On Tue, Jan 11, 2022 at 9:01 PM Blake McBride <blake1024@gmail.com> wrote: > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> > Well, provided there are DVI-to-whatever converters then. it's a systems problem. What we really need is gcc support for some processor that is easy to emulate (at least the userland). Historically that was MIPS; now it's probably RISC/V. Or, I suppose, MMIX; there is a very partial Verilog description at <https://github.com/tommythorn/fpgammix> that would make it possible to create a hardware integer MMIX CPU using FPGAs. And .PDF isn't? >> > > No. It isn't. It is an Adobe product. > Up to a point, Minister. PDF/A is an ISO standard that tracks PDF 1.4 or PDF 1.7. It is meant for creating archivable PDFs, so it excludes linked fonts (as opposed to embedded ones, which are allowed), JavaScript, audio/video, encryption, external references, etc. For troff purposes, we don't need any of that, so it's just a matter of setting the metadata correctly. ISO standards can be withdrawn, but they remain available; I doubt this one will be, since libraries are depending on it. There are lots of FLOSS toolkits to generate PDFs. [-- Attachment #2: Type: text/html, Size: 3010 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 19:54 ` John Cowan @ 2022-01-13 10:13 ` Thomas Paulsen 2022-01-13 20:00 ` John Cowan 0 siblings, 1 reply; 102+ messages in thread From: Thomas Paulsen @ 2022-01-13 10:13 UTC (permalink / raw) To: John Cowan; +Cc: tuhs nevertheless it's still an Adobe product. --- Ursprüngliche Nachricht --- Von: John Cowan <cowan@ccil.org> Datum: 12.01.2022 20:54:34 An: Blake McBride <blake1024@gmail.com> Betreff: Re: [TUHS] TeX and groff (was: roff(7)) an Adobe product. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-13 10:13 ` Thomas Paulsen @ 2022-01-13 20:00 ` John Cowan 0 siblings, 0 replies; 102+ messages in thread From: John Cowan @ 2022-01-13 20:00 UTC (permalink / raw) To: Thomas Paulsen; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 504 bytes --] Only in the sense that Fortran is an IBM product. (IBM's Fortran compilers and runtimes are IBM products, but that's another matter.) On Thu, Jan 13, 2022 at 5:13 AM Thomas Paulsen <thomas.paulsen@firemail.de> wrote: > nevertheless it's still an Adobe product. > > --- Ursprüngliche Nachricht --- > Von: John Cowan <cowan@ccil.org> > Datum: 12.01.2022 20:54:34 > An: Blake McBride <blake1024@gmail.com> > Betreff: Re: [TUHS] TeX and groff (was: roff(7)) > > an Adobe product. > > > [-- Attachment #2: Type: text/html, Size: 1033 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 19:00 ` Blake McBride 2022-01-10 20:21 ` Jon Forrest @ 2022-01-10 20:33 ` Larry McVoy 2022-01-10 20:37 ` Richard Salz 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton 2022-01-10 20:46 ` Steffen Nurpmeso 2022-01-11 1:59 ` [TUHS] Demise of " Greg 'groggy' Lehey 3 siblings, 2 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-10 20:33 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list, Douglas McIlroy On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: > 2. Looking at the output, it is my opinion that TeX produces > better-looking documents. It's a double edged sword. TeX looks better but you instantly know it is TeX, it has a particular look. Troff looks just fine to me, and you don't know it is Troff, Word, or what. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 20:33 ` Larry McVoy @ 2022-01-10 20:37 ` Richard Salz 2022-01-10 21:04 ` Dan Cross 2022-01-11 1:52 ` [TUHS] Recognizing TeX (was: TeX and groff (was: roff(7))) Greg 'groggy' Lehey 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton 1 sibling, 2 replies; 102+ messages in thread From: Richard Salz @ 2022-01-10 20:37 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 300 bytes --] > It's a double edged sword. TeX looks better but you instantly know it is > TeX, it has a particular look. Troff looks just fine to me, and you don't > know it is Troff, Word, or what. > Oh, does *roff support Comic Sans now? Less flippantly, I know it's TeX is probably mostly about the fonts. [-- Attachment #2: Type: text/html, Size: 565 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 20:37 ` Richard Salz @ 2022-01-10 21:04 ` Dan Cross 2022-01-10 21:48 ` Nemo Nusquam 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 1:52 ` [TUHS] Recognizing TeX (was: TeX and groff (was: roff(7))) Greg 'groggy' Lehey 1 sibling, 2 replies; 102+ messages in thread From: Dan Cross @ 2022-01-10 21:04 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 734 bytes --] On Mon, Jan 10, 2022 at 3:37 PM Richard Salz <rich.salz@gmail.com> wrote: > > It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. >> > > Oh, does *roff support Comic Sans now? > This is interesting; I've always felt like I could pick out troff pretty readily; I agree that TeX has a certain "look" to it (at least by default), but I always felt the same about troff as well. Less flippantly, I know it's TeX is probably mostly about the fonts. > Agreed, I suspect the same is true of my subjective interpretation of troff as well. Well, with TeX, it's the fonts and the math. - Dan C. [-- Attachment #2: Type: text/html, Size: 1539 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 21:04 ` Dan Cross @ 2022-01-10 21:48 ` Nemo Nusquam 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 1 sibling, 0 replies; 102+ messages in thread From: Nemo Nusquam @ 2022-01-10 21:48 UTC (permalink / raw) To: tuhs On 2022-01-10 16:04, Dan Cross wrote (in part): > Well, with TeX, it's the fonts and the math. Well, my preferred font with LaTeX is Palatino. N. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 21:04 ` Dan Cross 2022-01-10 21:48 ` Nemo Nusquam @ 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:47 ` Larry McVoy 2022-01-22 2:34 ` [TUHS] troff environments, traps, and diversions (was: TeX and groff) Branden Robinson 1 sibling, 2 replies; 102+ messages in thread From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-11 2:25 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS main list, Douglas McIlroy Dan Cross writes: > This is interesting; I've always felt like I could pick out troff pretty > readily; I agree that TeX has a certain "look" to it (at least by default), > but I always felt the same about troff as well. My guess this is more about how ms(7) does page layout. I can spot those documents from a mile away :-) But older versions of troff can often be spotted by how box corners don't always line up properly. A lot of people get turned off by how troff markup can often look like line noise. That's true, but if you spend the time to actually learn the syntax (and it's really not that hard), you can't help but be overwhelmed by the beauty of its self-consistency. Although after three decades I still can't wrap my head around traps and diversions :-P --lyndon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-11 2:47 ` Larry McVoy 2022-01-22 2:34 ` [TUHS] troff environments, traps, and diversions (was: TeX and groff) Branden Robinson 1 sibling, 0 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-11 2:47 UTC (permalink / raw) To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: TUHS main list, Douglas McIlroy On Mon, Jan 10, 2022 at 06:25:08PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > but be overwhelmed by the beauty of its self-consistency. Although > after three decades I still can't wrap my head around traps and > diversions :-P Traps are easy, end of the page. Diversions are easy, it's a bucket to put stuff in. Environments are harder. ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] troff environments, traps, and diversions (was: TeX and groff) 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:47 ` Larry McVoy @ 2022-01-22 2:34 ` Branden Robinson 2022-01-22 16:02 ` Douglas McIlroy 1 sibling, 1 reply; 102+ messages in thread From: Branden Robinson @ 2022-01-22 2:34 UTC (permalink / raw) To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: tuhs [-- Attachment #1.1: Type: text/plain, Size: 2667 bytes --] On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote: > A lot of people get turned off by how troff markup can often look like > line noise. That's true, but if you spend the time to actually learn > the syntax (and it's really not that hard), you can't help but be > overwhelmed by the beauty of its self-consistency. Although after > three decades I still can't wrap my head around traps and diversions > :-P It seems like a lot of people get stuck on the dread trio of traps, diversions, and environments. Some old groff documentation did not, I think, help matters very much by characterizing them as "advanced" and particularly by comparing diversions to pointers in C. I've been rewriting a lot of groff's documentation over the past five years. Here's my attempt to introduce these 3 concepts in the groff(7) page of the forthcoming 1.23 release. Let me know how I can improve it. (I retiterate that it's just an introduction--there is much more detail about all three later in the page and in groff's Texinfo manual, much of which has parallel content to its man pages.) A further few language elements arise as page layouts become more sophisticated and demanding. Environments collect formatting parameters like line length and typeface. A diversion stores formatted output for later use. A trap is a condition on the input or output, tested automatically by the formatter, that is associated with a macro, causing it to be called when that condition is fulfilled. Footnote support often exercises all three of the foregoing features. A simple implementation might work as follows. A pair of macros is defined: one starts a footnote and the other ends it. The author calls the first macro where a footnote marker is desired. The macro establishes a diversion so that the footnote text is collected at the place in the body text where its corresponding marker appears. An environment is created for the footnote so that it is set at a smaller typeface. The footnote text is formatted in the diversion using that environment, but it does not yet appear in the output. The document author calls the footnote end macro, which returns to the previous environment and ends the diversion. Later, after much more body text in the document, a trap, set a small distance above the page bottom, is sprung. The macro called by the trap draws a line across the page and emits the stored diversion. Thus, the footnote is rendered. Regards, Branden [-- Attachment #1.2: Type: text/html, Size: 1384 bytes --] [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] troff environments, traps, and diversions (was: TeX and groff) 2022-01-22 2:34 ` [TUHS] troff environments, traps, and diversions (was: TeX and groff) Branden Robinson @ 2022-01-22 16:02 ` Douglas McIlroy 2022-01-23 19:45 ` Jon Steinhart 2022-01-23 22:26 ` Jon Steinhart 0 siblings, 2 replies; 102+ messages in thread From: Douglas McIlroy @ 2022-01-22 16:02 UTC (permalink / raw) To: Branden Robinson; +Cc: tuhs Branden, I like these intro paragraphs and the elision of the ominous adjective, "advanced". > An environment is created for the footnote so that it is set at a smaller typeface. To avoid implying that one must create an environment with each footnote and to illustrate that environments are collections of settings, you might say something like this > Switch to a previously created footnote environment with a smaller typeface and distinctive line length. Doug On Fri, Jan 21, 2022 at 9:34 PM Branden Robinson <g.branden.robinson@gmail.com> wrote: > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > <lyndon@orthanc.ca> wrote: > > A lot of people get turned off by how troff markup can often look like > > line noise. That's true, but if you spend the time to actually learn > > the syntax (and it's really not that hard), you can't help but be > > overwhelmed by the beauty of its self-consistency. Although after > > three decades I still can't wrap my head around traps and diversions > > :-P > > It seems like a lot of people get stuck on the dread trio of traps, > diversions, and environments. Some old groff documentation did not, I > think, help matters very much by characterizing them as "advanced" and > particularly by comparing diversions to pointers in C. I've been > rewriting a lot of groff's documentation over the past five years. > > Here's my attempt to introduce these 3 concepts in the groff(7) page of > the forthcoming 1.23 release. Let me know how I can improve it. (I > retiterate that it's just an introduction--there is much more detail > about all three later in the page and in groff's Texinfo manual, much of > which has parallel content to its man pages.) > > A further few language elements arise as page layouts become more > sophisticated and demanding. Environments collect formatting > parameters like line length and typeface. A diversion stores > formatted output for later use. A trap is a condition on the > input or output, tested automatically by the formatter, that is > associated with a macro, causing it to be called when that > condition is fulfilled. > > Footnote support often exercises all three of the foregoing > features. A simple implementation might work as follows. A pair > of macros is defined: one starts a footnote and the other ends > it. The author calls the first macro where a footnote marker is > desired. The macro establishes a diversion so that the footnote > text is collected at the place in the body text where its > corresponding marker appears. An environment is created for the > footnote so that it is set at a smaller typeface. The footnote > text is formatted in the diversion using that environment, but it > does not yet appear in the output. The document author calls the > footnote end macro, which returns to the previous environment and > ends the diversion. Later, after much more body text in the > document, a trap, set a small distance above the page bottom, is > sprung. The macro called by the trap draws a line across the > page and emits the stored diversion. Thus, the footnote is > rendered. > > Regards, > Branden > Foo > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote: >> >> Dan Cross writes: >> >> > This is interesting; I've always felt like I could pick out troff pretty >> > readily; I agree that TeX has a certain "look" to it (at least by default), >> > but I always felt the same about troff as well. >> >> My guess this is more about how ms(7) does page layout. I can spot >> those documents from a mile away :-) >> >> But older versions of troff can often be spotted by how box corners >> don't always line up properly. >> >> A lot of people get turned off by how troff markup can often look >> like line noise. That's true, but if you spend the time to actually >> learn the syntax (and it's really not that hard), you can't help >> but be overwhelmed by the beauty of its self-consistency. Although >> after three decades I still can't wrap my head around traps and >> diversions :-P >> >> --lyndon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] troff environments, traps, and diversions (was: TeX and groff) 2022-01-22 16:02 ` Douglas McIlroy @ 2022-01-23 19:45 ` Jon Steinhart 2022-01-23 22:26 ` Jon Steinhart 1 sibling, 0 replies; 102+ messages in thread From: Jon Steinhart @ 2022-01-23 19:45 UTC (permalink / raw) To: tuhs On Fri, Jan 21, 2022 at 9:34 PM Branden Robinson <g.branden.robinson@gmail.com> wrote: > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > <lyndon@orthanc.ca> wrote: > > A lot of people get turned off by how troff markup can often look like > > line noise. That's true, but if you spend the time to actually learn > > the syntax (and it's really not that hard), you can't help but be > > overwhelmed by the beauty of its self-consistency. Although after > > three decades I still can't wrap my head around traps and diversions > > :-P > > It seems like a lot of people get stuck on the dread trio of traps, > diversions, and environments. Some old groff documentation did not, I > think, help matters very much by characterizing them as "advanced" and > particularly by comparing diversions to pointers in C. I've been > rewriting a lot of groff's documentation over the past five years. > > Here's my attempt to introduce these 3 concepts in the groff(7) page of > the forthcoming 1.23 release. Let me know how I can improve it. (I > retiterate that it's just an introduction--there is much more detail > about all three later in the page and in groff's Texinfo manual, much of > which has parallel content to its man pages.) > > A further few language elements arise as page layouts become more > sophisticated and demanding. Environments collect formatting > parameters like line length and typeface. A diversion stores > formatted output for later use. A trap is a condition on the > input or output, tested automatically by the formatter, that is > associated with a macro, causing it to be called when that > condition is fulfilled. > > Footnote support often exercises all three of the foregoing > features. A simple implementation might work as follows. A pair > of macros is defined: one starts a footnote and the other ends > it. The author calls the first macro where a footnote marker is > desired. The macro establishes a diversion so that the footnote > text is collected at the place in the body text where its > corresponding marker appears. An environment is created for the > footnote so that it is set at a smaller typeface. The footnote > text is formatted in the diversion using that environment, but it > does not yet appear in the output. The document author calls the > footnote end macro, which returns to the previous environment and > ends the diversion. Later, after much more body text in the > document, a trap, set a small distance above the page bottom, is > sprung. The macro called by the trap draws a line across the > page and emits the stored diversion. Thus, the footnote is > rendered. > > Regards, > Branden > Foo On Lyndon's comment - if you're trying to get a new generation of troff users keep in mind that to younger folks than us line noise is a reason to get a surge protector. And if they have seen phone line noise, I still have a stack of old modems in the basement for them. And troff is a lot less like line noise that OpenOffice XML. I like the proposed improvements in the docs but would go further. o As per an earlier thread, I would explain the string/number register stuff in programming language terms; these are variables. And number registers have things like auto-increment and all that. It may be *technically* correct to say that registers are interpolated, but would be way more accessible to talk about the value of a variable. o It would be nice to have a table mapping groff constructs into those from other programming languages. Common ones, that is, not perl. Mentioned variables above, to me macros are functions, there are a few control constructs. Explain this stuff in terms that people are familiar with, try to avoid crufty language. o I think that it would be helpful to summarize that troff was originally written for smaller computers which required compromises such as the one and two character naming scheme. And a table that shows how that scheme has been compatibly expanded since. Better than hiding this in the description of every request that uses names. o I think that an important point to make about diversions is that they're a bit like scratch paper; that one can scribble on it and take measurements on them to decide what to do. For example, dumping a paragraph into a diversion and then measuring it to see if it will fit unbroken on what's left of a page. o The description of traps could be expanded. I would say something like the original traps were a vertical location on a page, and that since then the term has been overloaded with number of additional varieties. Jon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] troff environments, traps, and diversions (was: TeX and groff) 2022-01-22 16:02 ` Douglas McIlroy 2022-01-23 19:45 ` Jon Steinhart @ 2022-01-23 22:26 ` Jon Steinhart 1 sibling, 0 replies; 102+ messages in thread From: Jon Steinhart @ 2022-01-23 22:26 UTC (permalink / raw) To: tuhs Thinking about it some more, I think that it would help to talk about traps as interrupts or events. That works well with thinking about macros as functions as traps essentially fire of interrupt handlers which are macros. ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] Recognizing TeX (was: TeX and groff (was: roff(7))) 2022-01-10 20:37 ` Richard Salz 2022-01-10 21:04 ` Dan Cross @ 2022-01-11 1:52 ` Greg 'groggy' Lehey 1 sibling, 0 replies; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-11 1:52 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 764 bytes --] On Monday, 10 January 2022 at 15:37:01 -0500, Richard Salz wrote: >> It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. > > Less flippantly, I know it's TeX is probably mostly about the fonts. Agreed. There's also something about the default layout with overly large margins. But I know how to change fonts on groff; my attempts with TeX were complete failures. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 20:33 ` Larry McVoy 2022-01-10 20:37 ` Richard Salz @ 2022-01-12 1:19 ` Mary Ann Horton 2022-01-12 2:03 ` Blake McBride ` (2 more replies) 1 sibling, 3 replies; 102+ messages in thread From: Mary Ann Horton @ 2022-01-12 1:19 UTC (permalink / raw) To: tuhs I recall attending a TeX lecture by Knuth around 1981. He said he wasn't satisfied with the character layout from other formatting programs, which drove him to write TeX. He illustrated in great detail the kerning and exact placement of the font characters next to each other. I couldn't tell the difference, but clearly it was very important to him. He wanted his documents to look perfect. On 1/10/22 12:33 PM, Larry McVoy wrote: > On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: >> 2. Looking at the output, it is my opinion that TeX produces >> better-looking documents. > It's a double edged sword. TeX looks better but you instantly know it is > TeX, it has a particular look. Troff looks just fine to me, and you don't > know it is Troff, Word, or what. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton @ 2022-01-12 2:03 ` Blake McBride 2022-01-12 2:10 ` Bakul Shah 2022-01-12 16:48 ` Steffen Nurpmeso 2 siblings, 0 replies; 102+ messages in thread From: Blake McBride @ 2022-01-12 2:03 UTC (permalink / raw) To: Mary Ann Horton; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 661 bytes --] On Tue, Jan 11, 2022 at 7:20 PM Mary Ann Horton <mah@mhorton.net> wrote: > I recall attending a TeX lecture by Knuth around 1981. He said he wasn't > satisfied with the character layout from other formatting programs, > which drove him to write TeX. He illustrated in great detail the kerning > and exact placement of the font characters next to each other. I > couldn't tell the difference, but clearly it was very important to him. > He wanted his documents to look perfect. > Yes! That goes to one of my original points. While it is true that CM fonts have a particular look that may be interpreted as "better", there is a lot more to it. Blake McBride [-- Attachment #2: Type: text/html, Size: 1063 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton 2022-01-12 2:03 ` Blake McBride @ 2022-01-12 2:10 ` Bakul Shah 2022-01-12 3:44 ` Dan Cross 2022-01-12 16:48 ` Steffen Nurpmeso 2 siblings, 1 reply; 102+ messages in thread From: Bakul Shah @ 2022-01-12 2:10 UTC (permalink / raw) To: TUHS main list Don Knuth talks at length about how TeX & MetaFont came about etc. in his Web of Stories interview in parts 50 through 70. In Part 56 he does say he looked at "the system developed at Bell Labs", presumably troff. In part 68 he talks about the importance of stability fot TeX and later talks about LaTeX and ConTeXt. https://www.youtube.com/watch?v=UzqhuWBClcM&list=PLVV0r6CmEsFzeNLngr1JqyQki3wdoGrCn&index=56 I must say I am a fan of TeX/LaTeX and not a fan of nroff/troff -- I don't like the troff look and I don't like the markup. The nice thing is we can choose whatever typesetting tools we want! I played with other alternatives such as lout and Sile but didn't like them all that much. I immediately liked the TeX's model of boxes and glue. I like the fact that I can typeset Indic language text beautifully. But like any complex tool, you have to take time to learn it and practice to get proficient at it. At the same time I am not a fan of the way Knuth does literate programming. What I'd like is a two view editor where I can jump from code to related documentation and vice versa. And when you're working on one, the related part in the other view highlighted. In this world I don't want to deal with files and directories -- just one virtual document, however it is stored put under version control! > On Jan 11, 2022, at 5:19 PM, Mary Ann Horton <mah@mhorton.net> wrote: > > I recall attending a TeX lecture by Knuth around 1981. He said he wasn't satisfied with the character layout from other formatting programs, which drove him to write TeX. He illustrated in great detail the kerning and exact placement of the font characters next to each other. I couldn't tell the difference, but clearly it was very important to him. He wanted his documents to look perfect. > > On 1/10/22 12:33 PM, Larry McVoy wrote: >> On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: >>> 2. Looking at the output, it is my opinion that TeX produces >>> better-looking documents. >> It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 2:10 ` Bakul Shah @ 2022-01-12 3:44 ` Dan Cross 0 siblings, 0 replies; 102+ messages in thread From: Dan Cross @ 2022-01-12 3:44 UTC (permalink / raw) To: Bakul Shah; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 3239 bytes --] On Tue, Jan 11, 2022 at 9:11 PM Bakul Shah <bakul@iitbombay.org> wrote: > Don Knuth talks at length about how TeX & MetaFont came about etc. in his Web of Stories interview in parts 50 through 70. In Part 56 he does say he looked at "the system developed at Bell Labs", presumably troff. Among the Bell Labs technical reports I read when I was younger, a trilogy by MD McIlroy on the challenges drawing ellipses stand out: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3440&rep=rep1&type=pdf These stuck in my mind and some relatively short time later, I read how the analogous problem was approached in TeX. The solution there was to treat the shape as if it were drawn using a pen with a diamond-shaped nib. From the MetaFont book: Similarly, some diagonal lines of slope~1 digitize to be twice as dark as others, when a truly circular pen is considered. But the diamond-shaped nib that \MF\ uses for a pencircle of diameter~1 does not have this defect; all straight lines of the same slope will digitize to lines of uniform darkness. Moreover, curved lines drawn with the diamond nib always yield one pixel per column when they move more-or-less horizontally (with slopes between $+1$ and $-1$), and they always yield one pixel per row when they move vertically. By contrast, the outlines of curves drawn with circular pens produce occasional ``blots.'' Circles and ellipses of all diameters can profitably be replaced by polygons whose sub-pixel corrections to the ideal shape will produce better digitizations; \MF\ does this in accordance with the interesting theory developed by John~D. ^{Hobby} in his Ph.D. dissertation (Stanford University, 1985). If I can be so bold as to offer an interpretation: Doug's approximations treat ellipses as mathematical objects and algorithmically determine what pixels are closest to points on the infinitesimally-thin curves, while Knuth's (or one his students') method acknowledges that the curve has a width defined by the nib; any "pixel" the nib touches becomes part of the figure. Perhaps I'm wrong on the details, but it hardly matters; my point is that there was clearly interesting work done in the area in both places. I find it impossible that neither Knuth nor Hobby were unaware of McIlroy's work and vice-versa; of course he would have known about and examined troff just as the Bell Labs folks knew about TeX. These were hot areas of practical research! This is also a good reminder that not only was Unix itself a subject of research, but it supported a lot of other research at Bell Labs and elsewhere. On this list, we tend to focus on the tool, but that tool was put to use building many more things as well. > [snip] > I must say I am a fan of TeX/LaTeX and not a fan of nroff/troff -- I don't like the troff look and I don't like the markup. I've always admired the look of troff. I wonder if, in retrospect, that is due to me mentally tying the presentation with so many formative documents that were strong early influences. Similarly, I love the look of Tex (even the CM fonts). They are of course different, but I find each beautiful in different ways. > The nice thing is we can choose whatever typesetting tools we want! This! - Dan C. [-- Attachment #2: Type: text/html, Size: 3757 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton 2022-01-12 2:03 ` Blake McBride 2022-01-12 2:10 ` Bakul Shah @ 2022-01-12 16:48 ` Steffen Nurpmeso 2 siblings, 0 replies; 102+ messages in thread From: Steffen Nurpmeso @ 2022-01-12 16:48 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs Mary Ann Horton wrote in <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net>: |I recall attending a TeX lecture by Knuth around 1981. He said he wasn't |satisfied with the character layout from other formatting programs, |which drove him to write TeX. He illustrated in great detail the kerning |and exact placement of the font characters next to each other. I |couldn't tell the difference, but clearly it was very important to him. |He wanted his documents to look perfect. I find with proof-reading roff provides very pleasant results; the german translation of K&R Programming in C (2nd Ed., ANSI C; so many credits to people on this list!!!) was produced in roff (Liangs hyphenation, Kernighans pic, Lesks tbl, Kernighan and Cherrys eqn, XENIX-adjusted d-i troff of ELAN; November 1989), it could not look better. I personally feel peeved when my documents do not look acceptable, but, other than that, from computer documents i do miss the spiritual, the contemplative and meditative side that calligraphically beautiful documents represent. Just recently for example a Thora that was saved from the flames reappeared here in Germany, it would be yet another massive loss of culture if this became binary or quantum. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] TeX and groff (was: roff(7)) 2022-01-10 19:00 ` Blake McBride 2022-01-10 20:21 ` Jon Forrest 2022-01-10 20:33 ` Larry McVoy @ 2022-01-10 20:46 ` Steffen Nurpmeso 2022-01-11 1:59 ` [TUHS] Demise of " Greg 'groggy' Lehey 3 siblings, 0 replies; 102+ messages in thread From: Steffen Nurpmeso @ 2022-01-10 20:46 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list, Douglas McIlroy Blake McBride wrote in <CABwHSOuMxgEJnNUczbcGhA_939q_XfwCLyqacaGpz3+AjdSqSQ@mail.gmail.com>: |I've used nroff/troff/TeX with many of their various macro packages over |about a 35 years span. During that time, I've done many single-page |documents as well as documents as long as 350 pages. I also modified a |version of nroff to create business forms for Laster printers. This is |still being used commercially. This is one person's opinion: | |1. Perhaps owing to my limited intelligence, and in spite of the fact that |I've used TeX successfully on many documents, I have never been able to |fully understand TeX. Apparently, it is too much for me. Troff, on the |other hand, has made full sense to me. I was able to make it do what I |wanted almost always. I enjoy using troff more because I find it simpler, |and therefore, more pleasant to use. | |2. Looking at the output, it is my opinion that TeX produces |better-looking documents. Perhaps this is just no more than one man's |esthetic opinion. I do not know what it is that I find better. It's just |the sense I get. On the other hand, I find troff output to be sufficiently |good in nearly all cases. Note that heirloom doctools (on github) is a SysV-derived *roff codebase which has been extended to use TeX paragraph algorithm, font kerning, true type fonts, etc. You need to explicitly code your macros to use these features. |3. troff is a good and reasonable tool. TeX is too big and complex an |environment in most cases. Although it is true that all of the complexity |of the TeX environment is successfully hidden in virtually all cases. I |find the huge and complex environment offputting. That is overly not true. You can start off with nothing but what TeX loads by default, plus epsf.tex and maybe colordvi.tex for some use cases and you have everything you need. I have never used it, but there is kertex and i am tracking it since, eh, July 2012. It is maintained. It is just the bare core, but includes more than i ever needed #?0|kent:kertex.tar_bomb_git$ git loca|wc -l 20 #?0|kent:kertex.tar_bomb_git$ du -sh . 13M . |Very unfortunately, I see troff disappearing. I've worked with a number of |teams over the last ten years. In every case, I was the oldest engineer. |Also, in each case, I was the only engineer who had even heard of troff. |They understand the problems of binary formats such as Word and |OpenOffice. Their solutions are things like markdown, AsciiDoc, et al. |They are doing this development and making use of these tools without |knowledge of troff. The same is true to a greater or lesser degree with |TeX, except that I've seen TeX used at universities. | |I like that groff and TeX are rock solid and well supported. In fact, I |wrote a report generator for a modern web development framework using |troff. I use it to develop reports on a routine basis. (kissweb.org) |Sadly, however, if word of their existence doesn't get out there, I see |them both disappearing in not much longer than a generation. This would be |sad indeed. Gee, the current hip top of the pops is to not even include generated documentation in release tarballs no more! Heck, i even know a project that took a year-long-not-modified manual page and converted it into some so-called text format. It thus needs a software which happily announces itself as "ronn: the opposite of roff", yieha! I mean ruby ok, there are some such tools which require Haskell, which in turn requires a binary runtime package (or a huuuuge source ball). No no, really not. I mean really. You develop it, you decide it is time for a release, you do test the convertability do you, why not include the 10 kilobytes for your is-anyway-almost-a-stub manual?? In fact these balls nowadays include .github subirectories for github workflows, which is much larger than the manual. Sigh. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-10 19:00 ` Blake McBride ` (2 preceding siblings ...) 2022-01-10 20:46 ` Steffen Nurpmeso @ 2022-01-11 1:59 ` Greg 'groggy' Lehey 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-12 0:32 ` Nemo Nusquam 3 siblings, 2 replies; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-11 1:59 UTC (permalink / raw) To: Blake McBride; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 950 bytes --] On Monday, 10 January 2022 at 13:00:15 -0600, Blake McBride wrote: > I like that groff and TeX are rock solid and well supported. In fact, I > wrote a report generator for a modern web development framework using > troff. I use it to develop reports on a routine basis. (kissweb.org) > Sadly, however, if word of their existence doesn't get out there, I see > them both disappearing in not much longer than a generation. This would be > sad indeed. As long as man pages are formatted with ?roff, I don't see it going away. I don't suppose many people use troff any more, but there are enough of us, and as long as man pages stay the way they are, I don't think we're in any danger. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 1:59 ` [TUHS] Demise of " Greg 'groggy' Lehey @ 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:42 ` Larry McVoy 2022-01-11 3:22 ` Adam Thornton 2022-01-12 0:32 ` Nemo Nusquam 1 sibling, 2 replies; 102+ messages in thread From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-11 2:13 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list, Douglas McIlroy Greg 'groggy' Lehey writes: > As long as man pages are formatted with ?roff, I don't see it going > away. I don't suppose many people use troff any more, but there are > enough of us, and as long as man pages stay the way they are, I don't > think we're in any danger. Well there is mandoc(1). But as time goes by they just seem to be re-implementing nroff. Of course that *must* be easier than just learning n/troff in the first place :-P I really don't understand this need to throw troff overboard. The code, both GNU and AT&T implementations, has been rock solid for decades. It's not like there are portability issues moving it between platforms. Provided the kiddies don't get in there and linuxify the code, of course. --lyndon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-11 2:42 ` Larry McVoy 2022-01-11 5:12 ` Greg 'groggy' Lehey ` (2 more replies) 2022-01-11 3:22 ` Adam Thornton 1 sibling, 3 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-11 2:42 UTC (permalink / raw) To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: TUHS main list, Douglas McIlroy On Mon, Jan 10, 2022 at 06:13:43PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Greg 'groggy' Lehey writes: > > > As long as man pages are formatted with ?roff, I don't see it going > > away. I don't suppose many people use troff any more, but there are > > enough of us, and as long as man pages stay the way they are, I don't > > think we're in any danger. > > Well there is mandoc(1). But as time goes by they just seem to be > re-implementing nroff. Of course that *must* be easier than just > learning n/troff in the first place :-P > > I really don't understand this need to throw troff overboard. It's docs. The *roff docs were locked up with the Unix license. Those docs were awesome, terse but full of info like the C book. Unlike the C book they were not readily available. My Uni had a Unix license so I still have the stack of docs, decades later, still useful. I firmly believe if those docs had been open source, freely available, whatever, we would all be using an evolved roff. I tried to get Microsoft, weakly, to make Word spit out roff. Never went anywhere and I think they would have screwed it up, there was a UI, Gremlin maybe? Don't remember, but it spit out pic. Horrible pic. The world would be a better place if Word spit out readable and modifiable roff. Imagine being in Word and going, yeah, I know what it is trying to do, let me drop down to -ms and do it. And Word took your changes. Tim O'Reilly got it, wrote a book about it but I think it was too little too late. Roff is not going to take over the world but Greg is right, man pages will keep it here. Some of us will help. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 2:42 ` Larry McVoy @ 2022-01-11 5:12 ` Greg 'groggy' Lehey 2022-01-11 5:59 ` John Labovitz 2022-01-11 8:57 ` arnold 2022-01-11 8:50 ` arnold 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole 2 siblings, 2 replies; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-11 5:12 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 1352 bytes --] On Monday, 10 January 2022 at 18:42:18 -0800, Larry McVoy wrote: > It's docs. The *roff docs were locked up with the Unix license. > Those docs were awesome, terse but full of info like the C book. > Unlike the C book they were not readily available. My Uni had a > Unix license so I still have the stack of docs, decades later, > still useful. Are these the PSD docs that are included with FreeBSD, or something else? > Tim O'Reilly got it, wrote a book about it but I think it was too > little too late. For a time perspective, this was 1987, before O'Reilly and Associates was founded. But the macros they (also, primarily, Dale Dougherty) described there are the basis for the macros they used at ORA when I started writing for them in 1993. Some time round the turn of the millennium they then migrated to DocBook, at least for the author interface. I think that they had some magic to then convert it to groff. So I don't think it was "too late"; the DocBook conversion suggests that the authors didn't like groff, though I thought that the conversion was a retrograde step. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 5:12 ` Greg 'groggy' Lehey @ 2022-01-11 5:59 ` John Labovitz 2022-01-11 8:57 ` arnold 1 sibling, 0 replies; 102+ messages in thread From: John Labovitz @ 2022-01-11 5:59 UTC (permalink / raw) To: TUHS main list On Jan 11, 2022, at 00:12, Greg 'groggy' Lehey <grog@lemis.com> wrote: > For a time perspective, this was 1987, before O'Reilly and Associates > was founded. But the macros they (also, primarily, Dale Dougherty) > described there are the basis for the macros they used at ORA when I > started writing for them in 1993. Some time round the turn of the > millennium they then migrated to DocBook, at least for the author > interface. I think that they had some magic to then convert it to > groff. So I don't think it was "too late"; the DocBook conversion > suggests that the authors didn't like groff, though I thought that the > conversion was a retrograde step. I think I can help fill out this puzzle. I started working for O’Reilly (specifically, for Dale) in late 1993, around the time the *roff -> DocBook/SGML transition was happening. I was hired to help develop Global Network Navigator, the first commercial website. Initially I created the first web ads (sorry) and later I was technical director of GNN. I recall that it wasn’t so much that people ‘didn’t like’ groff and its ilk, but that Tim and Dale realized that the future of publishing was going to be something far beyond simply print books, and they needed their content to have much more inherent structure and metadata than was offered by groff markup — whose purpose was primarily as a markup language for print. So the solution (as I observed it when I was there) was to translate the raw groff into a more abstract, structural markup — namely, SGML using the DocBook schema — and then to write conversion tools that would then re-generate groff, HTML, or something else. (The web/HTML was not necessarily the only future at that time!) That workflow also allowed manuscripts to be imported from other platforms (like Word) from authors who weren’t part of the Unix world, as O’Reilly branched out from strict Unix manuals into travel, finance, and other diverse worlds of content. For example, we were able to fairly easily republish the seminal _Whole Internet Catalog_ book as a major section of the GNN website, using commercial SGML->HTML tools plus a whole lotta Perl. :) —John ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 5:12 ` Greg 'groggy' Lehey 2022-01-11 5:59 ` John Labovitz @ 2022-01-11 8:57 ` arnold 2022-01-11 20:15 ` Jon Steinhart 1 sibling, 1 reply; 102+ messages in thread From: arnold @ 2022-01-11 8:57 UTC (permalink / raw) To: lm, grog; +Cc: tuhs, douglas.mcilroy "Greg 'groggy' Lehey" <grog@lemis.com> wrote: > But the macros they (also, primarily, Dale Dougherty) > described there are the basis for the macros they used at ORA when I > started writing for them in 1993. Some time round the turn of the > millennium they then migrated to DocBook, at least for the author > interface. I think that they had some magic to then convert it to > groff. So I don't think it was "too late"; the DocBook conversion > suggests that the authors didn't like groff, though I thought that the > conversion was a retrograde step. The DocBook conversion make it easy for them to generate HTML so that books could be put on CD and browsed with a web browser. I believe that was the main motivation. I wrote the second edition of "sed & awk" in troff and then they "converted" it to DocBook (with said backend that went back to troff for producing print). The conversion to DocBook was a disaster, such that I threatened to cancel doing the book. A lot of manual work later, the book came out OK, but boy was it painful. That backend was still in use ~ 2004 when I did "Unix In A Nutshell" and "Classic Shell Scripting" but they have moved on since then. Arnold P.S. Eric Raymond's love of DocBook not withstanding, it's a miserable markup language to have to work in. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 8:57 ` arnold @ 2022-01-11 20:15 ` Jon Steinhart 2022-01-11 20:22 ` Larry McVoy 0 siblings, 1 reply; 102+ messages in thread From: Jon Steinhart @ 2022-01-11 20:15 UTC (permalink / raw) To: tuhs arnold@skeeve.com writes: > The DocBook conversion make it easy for them to generate HTML so > that books could be put on CD and browsed with a web browser. > I believe that was the main motivation. Having been through this sort of stuff fairly recently, I wrote a short script that converted my troff macros into OpenOffice XML format because my publisher wanted Word. As I think I mentioned earlier, I also had a script that converted pic into SVG so that it could be included in Word docs. There were two difficulties. First, while I could have SVG pics, I had to insert them into the doc manually, couldn't figure how to do that in the XML. Second was that I ended up sending PDFs of the tables to one of the layout people as I couldn't come up with a decent way to convert those. An interesting aspect of this is that I grew up on the simple layout that was easy to do in tbl which is hard to do in Word as its tables are overly gaudy. The big thing missing from *roff from a publishing point of view is a good way to make comments and respond to them. Kind of a must-have when working with human (not text) editors. Jon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:15 ` Jon Steinhart @ 2022-01-11 20:22 ` Larry McVoy 2022-01-11 20:26 ` Jon Steinhart 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-11 20:22 UTC (permalink / raw) To: Jon Steinhart; +Cc: tuhs On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > The big thing missing from *roff from a publishing point of view is > a good way to make comments and respond to them. Kind of a must-have > when working with human (not text) editors. Source code control for the win. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:22 ` Larry McVoy @ 2022-01-11 20:26 ` Jon Steinhart 2022-01-11 20:36 ` Larry McVoy 0 siblings, 1 reply; 102+ messages in thread From: Jon Steinhart @ 2022-01-11 20:26 UTC (permalink / raw) To: tuhs Larry McVoy writes: > On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > > The big thing missing from *roff from a publishing point of view is > > a good way to make comments and respond to them. Kind of a must-have > > when working with human (not text) editors. > > Source code control for the win. Well, you're correct, but not practical with human editors. I'm not talking about revision history, I'm talking about the ability to easily highlight a portion of text and comment "did you mean foo?" and so on. That part of the production process feedback loop is missing. Of course, with *roff one could mostly produce one's own stuff without needing human editors and a production staff. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:26 ` Jon Steinhart @ 2022-01-11 20:36 ` Larry McVoy 2022-01-11 20:41 ` Jon Steinhart 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-11 20:36 UTC (permalink / raw) To: Jon Steinhart; +Cc: tuhs On Tue, Jan 11, 2022 at 12:26:12PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > > > The big thing missing from *roff from a publishing point of view is > > > a good way to make comments and respond to them. Kind of a must-have > > > when working with human (not text) editors. > > > > Source code control for the win. > > Well, you're correct, but not practical with human editors. I'm not > talking about revision history, I'm talking about the ability to easily > highlight a portion of text and comment "did you mean foo?" and so on. > That part of the production process feedback loop is missing. Of course, > with *roff one could mostly produce one's own stuff without needing human > editors and a production staff. I wrote the GUIs for BitKeeper, I could absolutely give you exactly what you want. Really, what you are describing is our code review system which could done done completely in a web browser but if you needed to hack on things, you cloned it and hacked on it and pushed. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:36 ` Larry McVoy @ 2022-01-11 20:41 ` Jon Steinhart 2022-01-11 20:49 ` Larry McVoy 0 siblings, 1 reply; 102+ messages in thread From: Jon Steinhart @ 2022-01-11 20:41 UTC (permalink / raw) To: tuhs Larry McVoy writes: > I wrote the GUIs for BitKeeper, I could absolutely give you exactly > what you want. Really, what you are describing is our code review > system which could done done completely in a web browser but if you > needed to hack on things, you cloned it and hacked on it and pushed. You were looking for a retirement project if I remember correctly. While it's probably out of scope for this mailing list, I would be interested in how you would handle things like an editor proposing a change that would involve not just word changes, but formatting. A non-roffer would need to have some way to show those changes and to have them pushed back into the appropriate requests and reformatted. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:41 ` Jon Steinhart @ 2022-01-11 20:49 ` Larry McVoy 2022-01-11 21:03 ` Jon Steinhart 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-11 20:49 UTC (permalink / raw) To: Jon Steinhart; +Cc: tuhs On Tue, Jan 11, 2022 at 12:41:37PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > I wrote the GUIs for BitKeeper, I could absolutely give you exactly > > what you want. Really, what you are describing is our code review > > system which could done done completely in a web browser but if you > > needed to hack on things, you cloned it and hacked on it and pushed. > > You were looking for a retirement project if I remember correctly. > While it's probably out of scope for this mailing list, I would be > interested in how you would handle things like an editor proposing > a change that would involve not just word changes, but formatting. > A non-roffer would need to have some way to show those changes and > to have them pushed back into the appropriate requests and reformatted. I've done this. We wrote our own contract with the help a great lawyer at Fenwick and West. I showed him how one document was producing around 8 different licenses, from your basic nobody version all the way up to Intel or HP or whoever master license agreements. Once he saw how you could do that, he said "this is so much better than maintaining 8 different, but mostly the same, documents". Exactly. He editted the roff input directly. I gave him a copy of BitKeeper and he used that to check in. Comments were check in comments. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:49 ` Larry McVoy @ 2022-01-11 21:03 ` Jon Steinhart 0 siblings, 0 replies; 102+ messages in thread From: Jon Steinhart @ 2022-01-11 21:03 UTC (permalink / raw) To: tuhs Larry McVoy writes: > He editted the roff input directly. I gave him a copy of BitKeeper > and he used that to check in. Comments were check in comments. Yeah, I get this. But I was dealing with a publisher whose staff was trained differently and weren't going to learn roff just for me. They (No Starch Press) do a lot of books per year, and it didn't make sense for them to retrain just for me. And, it wasn't just one editor; there were many passes with many different editors, some of whom were contract editors that Bill wasn't going to pay to learn new stuff. Bottom line is that I think that it would be awesome to have a WYSIWYG front end to the roff tools. Clearly not impossible as even Word and such as some sort of back end format which was only made possible by calling it markup instead of macros :-) ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 2:42 ` Larry McVoy 2022-01-11 5:12 ` Greg 'groggy' Lehey @ 2022-01-11 8:50 ` arnold 2022-01-11 14:00 ` Larry McVoy 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole 2 siblings, 1 reply; 102+ messages in thread From: arnold @ 2022-01-11 8:50 UTC (permalink / raw) To: lyndon, lm; +Cc: tuhs, douglas.mcilroy Larry McVoy <lm@mcvoy.com> wrote: > Tim O'Reilly got it, wrote a book about it but I think it was > too little too late. That book was open sourced ~ 2 decades ago. It was scanned, OCR'ed and converted back into troff. See https://www.oreilly.com/openbook/utp/ and in particular https://github.com/larrykollar/Unix-Text-Processing . Arnold ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 8:50 ` arnold @ 2022-01-11 14:00 ` Larry McVoy 2022-01-12 23:22 ` [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) Greg 'groggy' Lehey 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-11 14:00 UTC (permalink / raw) To: arnold; +Cc: tuhs, douglas.mcilroy On Tue, Jan 11, 2022 at 01:50:40AM -0700, arnold@skeeve.com wrote: > Larry McVoy <lm@mcvoy.com> wrote: > > > Tim O'Reilly got it, wrote a book about it but I think it was > > too little too late. > > That book was open sourced ~ 2 decades ago. It was scanned, OCR'ed > and converted back into troff. See https://www.oreilly.com/openbook/utp/ > and in particular https://github.com/larrykollar/Unix-Text-Processing . Yeah but it is 2022. 2 decades ago is 2002. TeX was first released in 1978. So it had 2+ decades where it was out there, the docs were out there, and Unix was doing the licensing dance. It may be ancient history but troff was not a given on every platform. nroff was there but troff was considered optional, you had to pay for it and a lot of vendors didn't see the value. So the docs and you weren't sure if you would have it at your next job, not good. I really wish it were different, I adore troff, I wrote something called webroff that took -ms input and produced our website (until we got marketing people and they replaced it with something "better", better my ass). I've written papers in TeX and while it isn't horrible, it's not great, I see nothing there that makes me want it over roff. ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) 2022-01-11 14:00 ` Larry McVoy @ 2022-01-12 23:22 ` Greg 'groggy' Lehey 2022-01-12 23:29 ` Greg 'groggy' Lehey 2022-01-12 23:32 ` Larry McVoy 0 siblings, 2 replies; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-12 23:22 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs, douglas.mcilroy [-- Attachment #1: Type: text/plain, Size: 794 bytes --] On Tuesday, 11 January 2022 at 6:00:05 -0800, Larry McVoy wrote: > It may be ancient history but troff was not a given on every > platform. nroff was there but troff was considered optional, you > had to pay for it and a lot of vendors didn't see the value. So the > docs and you weren't sure if you would have it at your next job, not > good. I've never used real troff, just groff. But from the man pages I understood that real troff only generated output for specific typesetters, while groff generated PostScript. Not so? Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) 2022-01-12 23:22 ` [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) Greg 'groggy' Lehey @ 2022-01-12 23:29 ` Greg 'groggy' Lehey 2022-01-12 23:32 ` Larry McVoy 1 sibling, 0 replies; 102+ messages in thread From: Greg 'groggy' Lehey @ 2022-01-12 23:29 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs, douglas.mcilroy [-- Attachment #1: Type: text/plain, Size: 603 bytes --] On Thursday, 13 January 2022 at 10:22:58 +1100, Greg 'groggy' Lehey wrote: > > I've never used real troff, just groff. But from the man pages I > understood that real troff only generated output for specific > typesetters, while groff generated PostScript. Not so? Never mind, I see that this has been done to death in another subthread. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) 2022-01-12 23:22 ` [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) Greg 'groggy' Lehey 2022-01-12 23:29 ` Greg 'groggy' Lehey @ 2022-01-12 23:32 ` Larry McVoy 1 sibling, 0 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-12 23:32 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: tuhs, douglas.mcilroy On Thu, Jan 13, 2022 at 10:22:58AM +1100, Greg 'groggy' Lehey wrote: > On Tuesday, 11 January 2022 at 6:00:05 -0800, Larry McVoy wrote: > > It may be ancient history but troff was not a given on every > > platform. nroff was there but troff was considered optional, you > > had to pay for it and a lot of vendors didn't see the value. So the > > docs and you weren't sure if you would have it at your next job, not > > good. > > I've never used real troff, just groff. But from the man pages I > understood that real troff only generated output for specific > typesetters, while groff generated PostScript. Not so? Yeah, it's been hashed out in this thread. I think originally it was for a C/A/T thingy, then somebody did a DVI which a virtual thingy with "drivers" for each target thingy, and then there was a pay version for postscript and then groff. Or something like that, if you read through this thread it's been hashed out pretty hard. And over on the groff mailing list they are putting the history in a man page going all the way back to RUNOFF. Loving the interest in roff, it's my favorite for writing papers or docs. Have developed a bit of a taste for asciidoc for simple stuff for the web. --lm ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 2:42 ` Larry McVoy 2022-01-11 5:12 ` Greg 'groggy' Lehey 2022-01-11 8:50 ` arnold @ 2022-01-11 15:47 ` Clem Cole 2022-01-11 16:55 ` Richard Salz ` (2 more replies) 2 siblings, 3 replies; 102+ messages in thread From: Clem Cole @ 2022-01-11 15:47 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 1507 bytes --] On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy <lm@mcvoy.com> wrote: > It's docs. The *roff docs were locked up with the Unix license. Larry point taken but ... I'm not so sure that specific statement is true. It may have >>seemed<< that way to you, but I'm fairly sure that in fact, it was not. The documents were published independently to the source and use of the binary license. I do think that some had an AT&T copyright on them, but I'm not even sure all of them had a copyright associated. The AT&T license in fact explicitly allowed replication of the documents that came with UNIX could be duplicated and distributed without violating the license. Numerous people sold copies of them. Any (student or not) could go into the MIT or Harvard Coop and buy a copy. Same in the Berkeley area, IIRC Stacy's [a famous Telgraph ave bookstore] had the BSD (as well as other systems) manuals. Beyond base duplication, numerous companies published parts of them and in particular parts if not all of the roff manual. For instance, a firm in Seattle called CSSC published a number of reference guides and use guides based on them [I just found a number of copies of some of them this weekend as I'm resetting up my basement. I have a number of duplicates that I am offering to the hive BTW]. I do believe that you are correct that both the sources (and associated binaries) to original nroff/groff and ditroff were licensed and needed and an AT&T license, but not the documents themselves. Clem [-- Attachment #2: Type: text/html, Size: 3536 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole @ 2022-01-11 16:55 ` Richard Salz 2022-01-11 18:49 ` Clem Cole 2022-01-11 19:20 ` John Cowan 2022-01-12 8:48 ` [TUHS] Demise of TeX and groff (was: roff(7)) arnold 2 siblings, 1 reply; 102+ messages in thread From: Richard Salz @ 2022-01-11 16:55 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 338 bytes --] On Tue, Jan 11, 2022 at 10:49 AM Clem Cole <clemc@ccc.com> wrote: > > On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy <lm@mcvoy.com> wrote: > >> It's docs. The *roff docs were locked up with the Unix license. > > > Larry point taken but ... I'm not so sure that specific statement is true. > I read it as s/locked up with/useless without/ [-- Attachment #2: Type: text/html, Size: 1245 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 16:55 ` Richard Salz @ 2022-01-11 18:49 ` Clem Cole 0 siblings, 0 replies; 102+ messages in thread From: Clem Cole @ 2022-01-11 18:49 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 1684 bytes --] Yeah, but the original Wang CAT4 version of troff was available without the extra license - its in the BSD tree. Now that was tied to the original UNIX license of course but it was available. Many (??most??) sites use the vcat program that Tom Ferrin wrote that used the Hershey Fonts to plot the output on a Versatec or later Varian plotter. The original Imagen which was forked from a Stanford project used that scheme until Adobe released Transcript. Brian's Device Independent Troff (ditroff) took another license either source or binary redistribution. DEC for instance, offered it as a layered product to Ultrix, and I think Sun did the same thing. At Masscomp I convinced management that tracking the sites that had it and which did not was too much of a PITA and if we just paid AT&T $15 and Adobe $1 a system, Engineering could just assume it was there. Of course, Tim and Dale both saw ditroff at Masscomp and took that (and Steve Talbot's modified mS macros and Janet Egan's set of book making tools) with them to ORA when they wrote the original NutShell book suite. I'm not sure Tim ever saw the original troff because as soon as I got there, I bought the ditroff and transcript licenses and rid us of the CAT4 stuff. Clem On Tue, Jan 11, 2022 at 11:56 AM Richard Salz <rich.salz@gmail.com> wrote: > > > On Tue, Jan 11, 2022 at 10:49 AM Clem Cole <clemc@ccc.com> wrote: > >> >> On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy <lm@mcvoy.com> wrote: >> >>> It's docs. The *roff docs were locked up with the Unix license. >> >> >> Larry point taken but ... I'm not so sure that specific statement is true. >> > > I read it as s/locked up with/useless without/ > > [-- Attachment #2: Type: text/html, Size: 3587 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole 2022-01-11 16:55 ` Richard Salz @ 2022-01-11 19:20 ` John Cowan 2022-01-11 20:06 ` Clem Cole 2022-01-12 8:48 ` [TUHS] Demise of TeX and groff (was: roff(7)) arnold 2 siblings, 1 reply; 102+ messages in thread From: John Cowan @ 2022-01-11 19:20 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 667 bytes --] On Tue, Jan 11, 2022 at 10:48 AM Clem Cole <clemc@ccc.com> wrote: > I do believe that you are correct that both the sources (and associated > binaries) to original nroff/groff and ditroff were licensed and needed and > an AT&T license, but not the documents themselves. > I assume you mean s/groff/troff/. There must have been some public access to the documentation like this that allowed James Clark to develop groff in the 1987-91 time frame, though. It's still the *roff shipped with *BSD. dformat, a pic preprocessor by Jon Bentley that displays bits-in-a-word pictures, is now available at <https://github.com/arnoldrobbins/dformat>; it's written in awk. [-- Attachment #2: Type: text/html, Size: 1684 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 19:20 ` John Cowan @ 2022-01-11 20:06 ` Clem Cole 2022-01-11 23:57 ` Warner Losh 2022-01-12 8:54 ` arnold 0 siblings, 2 replies; 102+ messages in thread From: Clem Cole @ 2022-01-11 20:06 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 3935 bytes --] On Tue, Jan 11, 2022 at 2:20 PM John Cowan <cowan@ccil.org> wrote: > I assume you mean s/groff/troff/. There must have been some public access > to the documentation like this that allowed James Clark to develop groff in > the 1987-91 time frame, though. It's still the *roff shipped with *BSD. > No, I mean troff... troff was written by Joseph Ossanna <https://en.wikipedia.org/wiki/Joe_Ossanna> for early version of UNIX. It output was for the CAT4 typesetter [which Wang eventually was the owner, although I believe when BTL bought the typesetter, the C/A/T folk was an independent company from Wang]. The output is funky binary format. The docs describing troff can be found in some of the early distributions [for look in Warrens archives]. IIRC V6 had the nroff sources [ https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s7], and v7 has the nroff/troff source [ https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff]. I've forgotten which earlier version had the binary in /bin (maybe v6 but possibly v5 too) and I'm fairly certain the original source leaked to the Universities before V7. I know we had the binary at CMU, before V7, but I don't remember when we got the source - but I suspect one our OYOC students brought it. I'll Let Noah speak for MIT and some one like Mary Ann speak for UCB before I got there. After Joe died and the BTL crew got a new APS5 typesetter, Brian set out to rewrite the code base to support any typesetting by using traditional compiler technology of converting the input to an ASCII representation that is walked by a seperate program that generates the device specific output. In fact it was this work (original done on V6) that forced Dennis (and I assume Steve Johnson) to update the C language a bit - which is what is described in K&R1. Brian's code and a version of DMR's updated C compiler was released independently as a package - hence the term 'typesetter C.' This compiler and the new document system took a seperate license. I had it at both CMU in the 70s and Tektronix -- I think Steve Glaser had it at Rice also - again ask someone else for other sites, including some of the early European ones. Later Brian's work was updated after V7 and included some new tools, and became known as Writer's Workbench, which eventually was entered in the 'toolchest.' At the time of the first release Brian published a paper / TR that describes the new version of troff (a.ka. ditroff), including some level of documentation for the intermediate language. That was published and would have been officially available to James. Clark certainly had access to both the papers as well as binaries. His work would eventually be called groff. I personally saw a version of it before it was taken into the Gnu project, in the early 1980s. I do not know if he had access to Brian's actual code under license when he reimplemented it in C++ creating a new implementation, as UCB did when they started to rewrite many of the utilities and main OS itself. The AT&T case basically said that once the implementations was released, AT&T could no longer call anything a trade secret, although they *do the own the IP and copyright* [and please not start a GPL/BSD license flame here -- the horse is so dead - please go back into the TUHS archives and read all about it if you are new here]. Larry is correct, that I do not believe that AT&T ever released that IP directly -- although the sources are certainly available at: The Heirloom Documentation Tools <https://n-t-roff.github.io/heirloom/doctools.html> I personally do not know the history. *But I believe* the concept is that when Sun bought out its license and was able to open source Solaris, the code base that goes back to Brian's original implementation became available at that point. Some one like Larry or Rob Gingell who lived some of that transition might be able to offer those details. [-- Attachment #2: Type: text/html, Size: 6158 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:06 ` Clem Cole @ 2022-01-11 23:57 ` Warner Losh 2022-01-12 0:03 ` Warner Losh 2022-01-12 8:54 ` arnold 1 sibling, 1 reply; 102+ messages in thread From: Warner Losh @ 2022-01-11 23:57 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 789 bytes --] On Tue, Jan 11, 2022 at 1:08 PM Clem Cole <clemc@ccc.com> wrote: > The AT&T case basically said that once the implementations was released, > AT&T could no longer call anything a trade secret, although they *do the > own the IP and copyright* > Not entirely true. There was a preliminary ruling that said that 32V might have lost its copyright protections because it was distributed outside of AT&T without proper copyright notices, as required by the pre-1980 copyright law. This detail was what caused AT&T to settle before it could become finalized (the preliminary ruling said there was a substantial likelihood that this would be the outcome, to be pedantic). To the extent that AT&T had complied with copyright laws requirements, they would retain their copyrights though. Warner [-- Attachment #2: Type: text/html, Size: 1254 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 23:57 ` Warner Losh @ 2022-01-12 0:03 ` Warner Losh 0 siblings, 0 replies; 102+ messages in thread From: Warner Losh @ 2022-01-12 0:03 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Douglas McIlroy [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] On Tue, Jan 11, 2022 at 4:57 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Jan 11, 2022 at 1:08 PM Clem Cole <clemc@ccc.com> wrote: > >> The AT&T case basically said that once the implementations was released, >> AT&T could no longer call anything a trade secret, although they *do the >> own the IP and copyright* >> > > Not entirely true. There was a preliminary ruling that said that 32V might > have lost its copyright protections because it was distributed outside of > AT&T without proper copyright notices, as required by the pre-1980 > copyright law. This detail was what caused AT&T to settle before it could > become finalized (the preliminary ruling said there was a substantial > likelihood that this would be the outcome, to be pedantic). To the extent > that AT&T had complied with copyright laws requirements, they would retain > their copyrights though. > See https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc. for a summary (see Pretrial section) and http://sco.tuxrocks.com/Docs/USL/Doc-92.html for the ruling itself that discusses the details). "Consequently, I find that Plaintiff has failed to demonstrate a likelihood that it can successfully defend its copyright in 32V. Plaintiff's claims of copyright violations are not a basis for injunctive relief." being the appropriate quote. Plantif == USL. Warner [-- Attachment #2: Type: text/html, Size: 2391 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 20:06 ` Clem Cole 2022-01-11 23:57 ` Warner Losh @ 2022-01-12 8:54 ` arnold 2022-01-12 15:17 ` Clem Cole 2022-01-12 16:33 ` Dan Cross 1 sibling, 2 replies; 102+ messages in thread From: arnold @ 2022-01-12 8:54 UTC (permalink / raw) To: clemc; +Cc: tuhs Clem, Once again, you have the timeline wrong on all this. The ditroff work was started in the summer of 1979, well after V6, Typesetter C and V7. Details are available at https://www.cs.princeton.edu/~bwk/202/202paper.pdf and https://www.cs.princeton.edu/~bwk/202/summer.reconstructed.pdf. Perhaps Doug can set the history straight on troff. Here is my understanding, corrections (from Doug) welcome: - Ossanna wrote the original nroff in assembly language - He rewrote it in C when the C/A/T was acquired At that time nroff/troff were built from mostly the same sources (as can be seen in the archives). Thanks, Arnold Clem Cole <clemc@ccc.com> wrote: > After Joe died and the BTL crew got a new APS5 typesetter, Brian set out to > rewrite the code base to support any typesetting by using traditional > compiler technology of converting the input to an ASCII representation that > is walked by a seperate program that generates the device specific output. > In fact it was this work (original done on V6) that forced Dennis (and I > assume Steve Johnson) to update the C language a bit - which is what is > described in K&R1. Brian's code and a version of DMR's updated C compiler > was released independently as a package - hence the term 'typesetter C.' > This compiler and the new document system took a seperate license. I had > it at both CMU in the 70s and Tektronix -- I think Steve Glaser had it at > Rice also - again ask someone else for other sites, including some of the > early European ones. > > Later Brian's work was updated after V7 and included some new tools, and > became known as Writer's Workbench, which eventually was entered in the > 'toolchest.' > > At the time of the first release Brian published a paper / TR that > describes the new version of troff (a.ka. ditroff), including some level of > documentation for the intermediate language. That was published and would > have been officially available to James. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-12 8:54 ` arnold @ 2022-01-12 15:17 ` Clem Cole 2022-01-12 16:33 ` Dan Cross 1 sibling, 0 replies; 102+ messages in thread From: Clem Cole @ 2022-01-12 15:17 UTC (permalink / raw) To: arnold; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 311 bytes --] On Wed, Jan 12, 2022 at 3:54 AM <arnold@skeeve.com> wrote: > > - Ossanna wrote the original nroff in assembly language > - He rewrote it in C when the C/A/T was acquired > At that time nroff/troff were built from mostly the same sources (as > can be seen in the archives). > That is also my understanding. [-- Attachment #2: Type: text/html, Size: 829 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-12 8:54 ` arnold 2022-01-12 15:17 ` Clem Cole @ 2022-01-12 16:33 ` Dan Cross 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson 1 sibling, 1 reply; 102+ messages in thread From: Dan Cross @ 2022-01-12 16:33 UTC (permalink / raw) To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2413 bytes --] On Wed, Jan 12, 2022 at 3:55 AM <arnold@skeeve.com> wrote: > [snip] > Perhaps Doug can set the history straight on troff. Here is my > understanding, > corrections (from Doug) welcome: > > - Ossanna wrote the original nroff in assembly language > - He rewrote it in C when the C/A/T was acquired > At that time nroff/troff were built from mostly the same sources (as > can be seen in the archives). > I have some questions about the earlier history. As I understand it, in the beginning there was RUNOFF, which I believe originated on CTSS? The CTSS sources contain a RUNOFF program that's made up of ~1100 lines of MAD and ~1300 lines of assembler. There is certainly a RUNOFF in Multics, written in BCPL (there's a small "outer module transfer vector" program in ALM). This is where it gets muddy for me; I understand this was roughly ported to unix as `roff` by Ken and that at this point, formatting was fairly primitive: suitable for hardcopy terminals and line printers, and could do things like center lines and so forth, but nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). Ossanna then took over and greatly expanded the capabilities of `roff`, adding macros and traps and making it Turing-complete; this was `nroff`, which grew to become `troff` once the C/A/T typesetter was acquired. Section 4.1 ("Text Processing") of Doug's "Research Unix Reader" above includes some tantalizing tidbits, particularly this, regarding `troff`: "It blew the manufacturer’s mind, and touched off a flurry of homemade documents in flamboyant layouts—good enough, however, to fool referees into suspecting that the manuscripts had been published before." Ooo, that last bit sounds like a good story! Doug, can you tell us more? - Dan C. PS: Something came up on the Multics mailing list recently that may be of local interest. Someone was looking for a set of troff macros used internally by Honeywell for the preparation of technical documentation and memoranda and it was asked whether this had been done on Multics? Apparently, `troff` never made it back to its ancestor's home, even though at some point circa the SVR2 era a C compiler was ported and it would have been, perhaps, possible. The answer to the original question was that that documentation had been prepared on a Unix machine of some kind; the macros seem lost to time. [-- Attachment #2: Type: text/html, Size: 2965 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* [TUHS] *roff history as told to GNU 2022-01-12 16:33 ` Dan Cross @ 2022-01-12 18:06 ` G. Branden Robinson 2022-01-12 18:34 ` Dan Halbert ` (3 more replies) 0 siblings, 4 replies; 102+ messages in thread From: G. Branden Robinson @ 2022-01-12 18:06 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 14428 bytes --] Hi, Dan, At 2022-01-12T11:33:35-0500, Dan Cross wrote: > I have some questions about the earlier history. I've been collecting a detailed narrative history not just of the *roff _programs_ but also of the development on the language in the roff(7) manual page. Below I'll share a current chunk of it that is planned for the next release (groff 1.23). It has been heavily revised since groff 1.22.4. Many of my revisions have been motivated by accounts from this list, from the "history of man pages" (more of a history of troff) at manpages.bsd.lv, and the minnie TUHS archive. > As I understand it, in the beginning there was RUNOFF, which I believe > originated on CTSS? The CTSS sources contain a RUNOFF program that's > made up of ~1100 lines of MAD and ~1300 lines of assembler. This is a detail I hadn't encountered before; instead I've read claims that distorted it into being a solely high-level language project. > There is certainly a RUNOFF in Multics, written in BCPL (there's a > small "outer module transfer vector" program in ALM). As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > This is where it gets muddy for me; I understand this was roughly > ported to unix as `roff` by Ken and that at this point, It is hard to find an account of this period that _isn't_ muddy. Claims from Murray Hill luminaries suggest that V0 and V1 Unix roffs were the collective work of Thompson, Ritchie, Ossanna, a fourth person who contributed the hyphenation algorithm (does someone have the name?), and McIlroy, because in Ritchie's words[1], this roff was "transliterated" from Doug's BCPL codebase. > formatting was fairly primitive: suitable for hardcopy terminals and > line printers, and could do things like center lines and so forth, but > nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). Yes. My contributions to groff's roff(7) page attempt to shed more light on this sort of thing. Sadly, at crucial periods sources and even documentation are missing. For example, there is an nroff entry in the Unix V2 manual table of contents, but no man page is present. In other early editions the reader is asked to see Ossanna for documentation, and it seems the corresponding artifacts might be lost to time. > Ossanna then took over and greatly expanded the capabilities of > `roff`, adding macros and traps and making it Turing-complete; this > was `nroff`, which grew to become `troff` once the C/A/T typesetter > was acquired. Yes. Here's what I have, though it looks better typeset[2]. Corrections from witnesses are warmly welcomed. Name roff - concepts and history of roff typesetting Description The term roff describes a family of document formatting systems known by names like troff, nroff, ditroff, and groff. A roff system consists of an extensible text formatting language and a set of programs for printing and converting to other text formats. Unix-like operating systems often distribute a roff system as a core package. [snip] History Computer-driven document formatting dates back to the 1960s. The roff system itself is intimately connected with the Unix operating system, but its roots go back to the earlier operating systems CTSS and Multics. The predecessor--RUNOFF roff's ancestor RUNOFF was written in the MAD language by Jerry Saltzer to prepare his Ph.D. thesis using the Compatible Time Sharing System (CTSS), a project of the Massachusetts Institute of Technology (MIT). The program is generally referred to in full capitals, both to distinguish it from its many descendants, and because bits were expensive in those days; five- and six-bit character encodings were still in widespread usage, and mixed- case alphabetics seen as a luxury. RUNOFF introduced a syntax of inlining formatting directives amid document text, by beginning a line with a period (an unlikely occurrence in human-readable material) followed by a "control word". Control words with obvious meaning like ".line length n" were supported as well as an abbreviation system; the latter came to overwhelm the former in popular usage and later derivatives of the program. A sample of control words from a RUNOFF manual of December 1966 <http:// web.mit.edu/Saltzer/www/publications/ctss/AH.9.01.html> was documented as follows (with the parameter notation slightly altered). The abbreviations will be familiar to roff veterans. Abbreviation Control word .ad .adjust .bp .begin page .br .break .ce .center .in .indent n .ll .line length n .nf .nofill .pl .paper length n .sp .space [n] In 1965, MIT's Project MAC teamed with Bell Telephone Laboratories and General Electric (GE) to inaugurate the Multics <http://www.multicians.org> project. After a few years, Bell Labs discontinued its participation in Multics, famously prompting the development of Unix. Meanwhile, Saltzer's RUNOFF proved influential, seeing many ports and derivations elsewhere. In 1969, Doug McIlroy wrote one such reimplementation of RUNOFF in the BCPL language for a GE 645 running GECOS at the Bell Labs location in Murray Hill, New Jersey. In its manual, the control commands were termed "requests", their two-letter names were canonical, and the control character was configurable with a .cc request. Other familiar requests emerged at this time; no-adjust (.na), need (.ne), page offset (.po), tab configuration (.ta, though it worked differently), temporary indent (.ti), character translation (.tr), and automatic underlining (.ul; on RUNOFF you had to backspace and underscore in the input yourself). .fi to enable filling of output lines got the name it retains to this day. Unix and roff roff was one of the first Unix programs. McIlroy's runoff was, in Dennis Ritchie's term, "transliterated" from BCPL to DEC PDP-7 assembly language for the fledgling Unix operating system. It saw its name shortened to roff (perhaps under the influence of Ken Thompson), while adding support for automatic hyphenation with .hc and .hy requests; a generalization of line spacing control with the .ls request; and what later roffs would call diversions, with "footnote" requests. This roff indirectly funded operating systems research at Murray Hill, for it was used to prepare patent applications for AT&T to the U.S. government. This arrangement enabled the group to acquire a PDP-11; roff promptly proved equal to the task of typesetting the first edition of the manual for what would later become known as "Unix Version 1", dated November 1971. Output from all of the foregoing programs was limited to line printers and paper terminals such the IBM 2471 (based on the Selectric line of typewriters) and the Teletype Corporation Model 37. Proportionally-spaced type was unknown. New roff and Typesetter roff The first years of Unix were spent in rapid evolution. The practicalities of preparing standardized documents like patent applications (and Unix manual pages), combined with McIlroy's enthusiasm for macro languages, perhaps created an irresistible pressure to make roff extensible. Joe Ossanna's nroff, literally a "new roff", was the outlet for this pressure. By the time of Unix Version 3 (February 1973)--and still in PDP-11 assembly language--it sported a swath of features now considered essential to roff systems: definition of macros (.de), diversion of text thence (.di), and removal thereof (.rm); trap planting (.wh; "when") and relocation (.ch; "change"); conditional processing (.if); and environments (.ev). Incremental improvements included assignment of the next page number (.pn); no-space mode (.ns) and restoration of vertical spacing (.rs); the saving (.sv) and output (.os) of vertical space; specification of replacement characters for tabs (.tc) and leaders (.lc); configuration of the no-break control character (.c2); shorthand to disable automatic hyphenation (.nh); a condensation of what were formerly six different requests for configuration of page "titles" (headers and footers) into one (.tl) with a length controlled separately from the line length (.lt); automatic line numbering (.nm); interactive input (.rd), which necessitated buffer-flushing (.fl), and was made convenient with early program cessation (.ex); source file inclusion in its modern form (.so; though RUNOFF had an ".append" control word for a similar purpose) and early advance to the next file argument (.nx); ignorable content (.ig); and programmable abort (.ab). Third Edition Unix also brought the pipe(2) system call, the explosive growth of a componentized system based around it, and a "filter model" that remains perceptible today. Equally importantly, the Bell Labs site in Murray Hill acquired a Graphic Systems C/A/T phototypesetter, and with it came the necessity of expanding the capabilities of a roff system to cope with proportionally-spaced type, multiple type sizes, and a variety of fonts. Ossanna wrote a parallel implementation of nroff for the C/A/T, dubbing it troff (for "typesetter roff"). Unfortunately, surviving documentation does not illustrate what requests were implemented at this time for C/A/T support; the troff(1) man page in Fourth Edition Unix (November 1973) does not feature a request list, unlike nroff(1). Apart from typesetter-driven features, Unix Version 4 roffs added string definitions (.ds); made the escape character configurable (.ec); and enabled the user to write diagnostics to the standard error stream (.tm). Around 1974, empowered with multiple type sizes, italics, and a symbol font specially commissioned by Bell Labs from Graphic Systems, Brian Kernighan and Lorinda Cherry implemented eqn for typesetting mathematics. In the same year, for Fifth Edition Unix, Ossanna combined and reimplemented the two roffs in C, using preprocessor conditions of that language to generate both from a single source tree. Ossanna documented the syntax of the input language to the nroff and troff programs in the "Troff User's Manual", first published in 1976, with further revisions as late as 1992 by Kernighan. (The original version was entitled "Nroff/Troff User's Manual", which may partially explain why roff practitioners have tended to refer to it by its AT&T document identifier, "CSTR #54".) Its final revision serves as the de facto specification of AT&T troff, and all subsequent implementors of roff systems have done so in its shadow. A small and simple set of roff macros was first used for the manual pages of Unix Version 4 and persisted for two further releases, but the first macro package to be formally described and installed was ms by Lesk in Version 6. He also wrote a manual, "Typing Documents on the Unix System", describing ms and basic nroff/troff usage, updating it as the package accrued features. Sixth Edition additionally saw the debut of the tbl preprocessor for formatting tables, also by Lesk. For Unix Version 7 (January 1979), McIlroy designed, implemented, and documented the man macro package, introducing most of the macros described in groff_man(7) today, and edited volume 1 of the Version 7 manual using it. Documents composed using ms featured in volume 2, edited by Kernighan. Ossanna had passed away unexpectedly in 1977, and after the release of Version 7, with the C/A/T typesetter becoming supplanted by alternative devices such as the Mergenthaler Linotron 202, Kernighan undertook a revision and rewrite of troff to generalize its design. To implement this revised architecture, he developed the font and device description file formats and the device-independent output format that remain in use today. He described these novelties in the article "A Typesetter-independent TROFF", last revised in 1982, and like the troff manual itself, it is widely known by a shorthand, "CSTR #97". Kernighan's innovations prepared troff well for the introduction of the Adobe PostScript language in 1982 and a vibrant market in laser printers with built-in interpreters for it. An output driver for PostScript, dpost, was swiftly developed. However, due to AT&T software licensing practices, Ossanna's troff, with its tight coupling to the capabilities of the C/A/T, remained in parallel distribution with device-independent troff throughout the 1980s, leading some developers to contrive translators for C/A/T-formatted documents to other devices. An example was vtroff for Versatec and Benson-Varian plotters. Today, however, all actively maintained troffs follow Kernighan's device- independent design. Regards, Branden [1] "The Evolution of the Unix Time-Sharing System", Ritchie, 1984 [2] Formatted with: groff -man -P-c -Tascii -rLL=72n -rHY=0 -dAD=l build/man/roff.7 (The `AD` string is new to groff 1.23 man(7).) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson @ 2022-01-12 18:34 ` Dan Halbert 2022-01-12 22:48 ` Clem Cole 2022-01-12 20:01 ` Dan Cross ` (2 subsequent siblings) 3 siblings, 1 reply; 102+ messages in thread From: Dan Halbert @ 2022-01-12 18:34 UTC (permalink / raw) To: tuhs On 1/12/22 13:06, G. Branden Robinson wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: >> I have some questions about the earlier history. >> >> I've been collecting a detailed narrative history not just of the *roff >> _programs_ but also of the development on the language in the roff(7) >> manual page. Below I'll share a current chunk of it that is planned for >> the next release (groff 1.23). It has been heavily revised since >> groff 1.22.4. Many of my revisions have been motivated by accounts from >> this list, from the "history of man pages" (more of a history of troff) >> at manpages.bsd.lv, and the minnie TUHS archive. I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX and TOPS-20. It probably was available earlier than that. Your history is covering the Unix side, but there is also a pretty robust DEC side. It was available on pretty much all the DEC machines. https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF has some mentions. Dan H. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 18:34 ` Dan Halbert @ 2022-01-12 22:48 ` Clem Cole 2022-01-12 23:27 ` Charles H. Sauer 0 siblings, 1 reply; 102+ messages in thread From: Clem Cole @ 2022-01-12 22:48 UTC (permalink / raw) To: Dan Halbert; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2472 bytes --] Dan/Branden -- don't forget that IBM had a flavor of the runoff family also at least by the early 1970s when I saw it. In fact, I learned it before either the DEC ones for the PDP-10s which I saw next, and only after that the UNIX family. We ran the IBM doc tool on TSS [often of 2741 style devices], and I think it ran on MTS. Pre-laser printer days, although CS an XGP, it was only 200 dpi (and was on the PDP-10s). So CMU computer center (IBM shop) even had a very high end printer with a golf ball (serial) output device that was in a locked room that was connected the 360 that they used to print 'special' letters on a fan folded paper that was super high quality and then run through the 'burster' to remove the edges and make it single sheets [Acceptance letters and other special things got printed on it by the computer center for the administration]. I don't remember much about that part of the process, other than the input/prep was from the IBM version of a runoff like program and as an operator, we had to learn to make it go and run things out on it as needed. But I do remember it was a PITA to output to that thing, but the SW also worked on a traditional 2741. As a member of the computer staff I had access to the 2741 in my office (for APL work), but could set it up as a standard 2741 and type papers on it late at night. On Wed, Jan 12, 2022 at 1:42 PM Dan Halbert <halbert@halwitz.org> wrote: > On 1/12/22 13:06, G. Branden Robinson wrote: > > Hi, Dan, > > > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > >> I have some questions about the earlier history. > >> > >> I've been collecting a detailed narrative history not just of the *roff > >> _programs_ but also of the development on the language in the roff(7) > >> manual page. Below I'll share a current chunk of it that is planned for > >> the next release (groff 1.23). It has been heavily revised since > >> groff 1.22.4. Many of my revisions have been motivated by accounts from > >> this list, from the "history of man pages" (more of a history of troff) > >> at manpages.bsd.lv, and the minnie TUHS archive. > > I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX > and TOPS-20. It probably was available earlier than that. Your history > is covering the Unix side, but there is also a pretty robust DEC side. > It was available on pretty much all the DEC machines. > https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF has some mentions. > > Dan H. > [-- Attachment #2: Type: text/html, Size: 3228 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 22:48 ` Clem Cole @ 2022-01-12 23:27 ` Charles H. Sauer 2022-01-13 0:35 ` Adam Thornton 0 siblings, 1 reply; 102+ messages in thread From: Charles H. Sauer @ 2022-01-12 23:27 UTC (permalink / raw) To: tuhs I try to avoid inserting non-Unix IBM stuff into TUHS, but since Clem opened the door, ... When I was at Yorktown 1975-77 and 1979-82, using Script (IBM's runoff) on VM/370 was very pleasant from my perspective, for papers, manuals and my three performance modeling books. IIRC when I got there Script output went to Versatecs for draft output and to APS5 for camera ready. By 1979, DCF superseded Script and 6670s superseded Versatecs for draft output. https://en.wikipedia.org/wiki/SCRIPT_(markup) and https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Language seem fair to me. While I'm inserting non-Unix stuff, and presuming some parallel between Yorktown and Murray Hill, the culture discussions make me point out that I intentionally avoided ties and suits my first couple of years, wearing a turtleneck for my initial interviews. Then my wife insisted I start wearing three piece wool suits, which were fine in the cold months requiring driving, but I avoided them when the weather was warm enough for me to cycle the five miles to the lab (https://technologists.com/songs/swans.html). CHS On 1/12/2022 4:48 PM, Clem Cole wrote: > Dan/Branden -- don't forget that IBM had a flavor of the runoff family > also at least by the early 1970s when I saw it. In fact, I learned it > before either the DEC ones for the PDP-10s which I saw next, and only > after that the UNIX family. We ran the IBM doc tool on TSS [often of > 2741 style devices], and I think it ran on MTS. Pre-laser printer days, > although CS an XGP, it was only 200 dpi (and was on the PDP-10s). So > CMU computer center (IBM shop) even had a very high end printer with a > golf ball (serial) output device that was in a locked room that was > connected the 360 that they used to print 'special' letters on a fan > folded paper that was super high quality and then run through the > 'burster' to remove the edges and make it single sheets [Acceptance > letters and other special things got printed on it by the computer > center for the administration]. I don't remember much about that part > of the process, other than the input/prep was from the IBM version of a > runoff like program and as an operator, we had to learn to make it go > and run things out on it as needed. But I do remember it was a PITA to > output to that thing, but the SW also worked on a traditional 2741. As > a member of the computer staff I had access to the 2741 in my office > (for APL work), but could set it up as a standard 2741 and type papers > on it late at night. > > On Wed, Jan 12, 2022 at 1:42 PM Dan Halbert <halbert@halwitz.org > <mailto:halbert@halwitz.org>> wrote: > > On 1/12/22 13:06, G. Branden Robinson wrote: > > Hi, Dan, > > > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > >> I have some questions about the earlier history. > >> > >> I've been collecting a detailed narrative history not just of > the *roff > >> _programs_ but also of the development on the language in the > roff(7) > >> manual page. Below I'll share a current chunk of it that is > planned for > >> the next release (groff 1.23). It has been heavily revised since > >> groff 1.22.4. Many of my revisions have been motivated by > accounts from > >> this list, from the "history of man pages" (more of a history of > troff) > >> at manpages.bsd.lv <http://manpages.bsd.lv>, and the minnie TUHS > archive. > > I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX > and TOPS-20. It probably was available earlier than that. Your history > is covering the Unix side, but there is also a pretty robust DEC side. > It was available on pretty much all the DEC machines. > https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF > <https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF> has some mentions. > > Dan H. > -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 23:27 ` Charles H. Sauer @ 2022-01-13 0:35 ` Adam Thornton 0 siblings, 0 replies; 102+ messages in thread From: Adam Thornton @ 2022-01-13 0:35 UTC (permalink / raw) To: Charles H. Sauer; +Cc: The Eunuchs Hysterical Society > On Jan 12, 2022, at 4:27 PM, Charles H. Sauer <sauer@technologists.com> wrote: > > I try to avoid inserting non-Unix IBM stuff into TUHS, but since Clem opened the door, ... > > When I was at Yorktown 1975-77 and 1979-82, using Script (IBM's runoff) on VM/370 was very pleasant from my perspective, for papers, manuals and my three performance modeling books. IIRC when I got there Script output went to Versatecs for draft output and to APS5 for camera ready. By 1979, DCF superseded Script and 6670s superseded Versatecs for draft output. https://en.wikipedia.org/wiki/SCRIPT_(markup) and https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Language seem fair to me. BookMaster might still be my favorite documentation-creation tool. Adam ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson 2022-01-12 18:34 ` Dan Halbert @ 2022-01-12 20:01 ` Dan Cross 2022-01-12 22:32 ` Clem Cole 2022-01-13 2:38 ` John Labovitz 3 siblings, 0 replies; 102+ messages in thread From: Dan Cross @ 2022-01-12 20:01 UTC (permalink / raw) To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3094 bytes --] On Wed, Jan 12, 2022 at 1:07 PM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > > I have some questions about the earlier history. > > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Below I'll share a current chunk of it that is planned for > the next release (groff 1.23). It has been heavily revised since > groff 1.22.4. Many of my revisions have been motivated by accounts from > this list, from the "history of man pages" (more of a history of troff) > at manpages.bsd.lv, and the minnie TUHS archive. > Very interesting. The email mentioning DSR from Dan Halbert linked to a wikipedia article that in turn links here: https://manpages.bsd.lv/history/saltzer_23_10_2011.txt This is an email from Jerry Saltzer that refers to a port of the _CTSS_ BCPL ROFF sources purportedly written by Doug. I wonder if that was actually a thing, or an error? > As I understand it, in the beginning there was RUNOFF, which I believe > > originated on CTSS? The CTSS sources contain a RUNOFF program that's > > made up of ~1100 lines of MAD and ~1300 lines of assembler. > > This is a detail I hadn't encountered before; instead I've read claims > that distorted it into being a solely high-level language project. > Fortunately, the source is online: https://github.com/rcornwell/ctss/tree/master/src/runoff The `.fap` files are assembly; for example https://github.com/rcornwell/ctss/blob/master/src/runoff/lmio12.fap Brief inspection shows the FAP code mostly dealing with very low-level details either interfacing with the system for IO/memory or character handling. Without further examination, I'd be willing to believe the bulk of the program's logic is in MAD. > There is certainly a RUNOFF in Multics, written in BCPL (there's a > > small "outer module transfer vector" program in ALM). > > As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > Indeed; one finds the following in at least one of the Multics RUNOFF source files: From https://github.com/dancrossnyc/multics/blob/main/library_dir_dir/system_library_standard/source/bound_runoff_.s.archive/runoff_mr1.bcpl : // Roff for MULTICS // // The first ROFF for Multics was written in March, 1969, by // Doug McIlroy of Bell Labs. Art Evans made extensive // modifications to it in May and June, 1969, adding many // comments and making various changes. // Footnoting added by Dennis Capps in 1970. // Maintained by Harwell Thrasher in 1971. // Many new features added and bugs fixed by R Mabee in 1971-1972. // RUNOFF and BCPL were brought over to the 6180 Multics (from 645) in May of 1973 by R F Mabee. The copyright statements on all of the runoff source files seem to be dated 1974 (I haven't looked at every one). > [snip] > Here's what I have, though it looks better typeset[2]. Corrections from > witnesses are warmly welcomed. [snip] > Thank you; that was very interesting. - Dan C. [-- Attachment #2: Type: text/html, Size: 4720 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson 2022-01-12 18:34 ` Dan Halbert 2022-01-12 20:01 ` Dan Cross @ 2022-01-12 22:32 ` Clem Cole 2022-01-13 2:38 ` John Labovitz 3 siblings, 0 replies; 102+ messages in thread From: Clem Cole @ 2022-01-12 22:32 UTC (permalink / raw) To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 15837 bytes --] Looks excellent -- friendly edit -- ditroff had nothing to do with vcat/vpr/vtroff. Tom Ferrin wrote the original at UCSF in the mid/late 70s -- the reasons was the the CAT typesetter was expensive and actually kinda nasty run. Many of us had plotters in those days and Tom's hack was a welcomed addition to the tool set. instead of: leading some developers to contrive translators for C/A/T-formatted documents to other devices. An example was vtroff for Versatec and Benson-Varian plotters. I offer: In mid/late 70s, Tom Ferrin a graphics researcher at UCSF using the font set released in the late 1960s, from Alan Hershey [ https://en.wikipedia.org/wiki/Hershey_fonts], wrote a program to simulate the C/A/T typesetter allowing the output of the original troff program to be 'plotted'. This program originally called vcat for virtual cat typesetter, was first distributed as part of an early USENIX distribution tape, but was eventually re-released in 3BSD and later BSD distributions as the UCB vpr(1) command and associated wrapper that call it was created called vtroff. On Wed, Jan 12, 2022 at 1:07 PM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > > I have some questions about the earlier history. > > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Below I'll share a current chunk of it that is planned for > the next release (groff 1.23). It has been heavily revised since > groff 1.22.4. Many of my revisions have been motivated by accounts from > this list, from the "history of man pages" (more of a history of troff) > at manpages.bsd.lv, and the minnie TUHS archive. > > > As I understand it, in the beginning there was RUNOFF, which I believe > > originated on CTSS? The CTSS sources contain a RUNOFF program that's > > made up of ~1100 lines of MAD and ~1300 lines of assembler. > > This is a detail I hadn't encountered before; instead I've read claims > that distorted it into being a solely high-level language project. > > > There is certainly a RUNOFF in Multics, written in BCPL (there's a > > small "outer module transfer vector" program in ALM). > > As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > > > This is where it gets muddy for me; I understand this was roughly > > ported to unix as `roff` by Ken and that at this point, > > It is hard to find an account of this period that _isn't_ muddy. Claims > from Murray Hill luminaries suggest that V0 and V1 Unix roffs were the > collective work of Thompson, Ritchie, Ossanna, a fourth person who > contributed the hyphenation algorithm (does someone have the name?), and > McIlroy, because in Ritchie's words[1], this roff was "transliterated" > from Doug's BCPL codebase. > > > formatting was fairly primitive: suitable for hardcopy terminals and > > line printers, and could do things like center lines and so forth, but > > nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). > > Yes. My contributions to groff's roff(7) page attempt to shed more > light on this sort of thing. Sadly, at crucial periods sources and even > documentation are missing. For example, there is an nroff entry in the > Unix V2 manual table of contents, but no man page is present. In other > early editions the reader is asked to see Ossanna for documentation, and > it seems the corresponding artifacts might be lost to time. > > > Ossanna then took over and greatly expanded the capabilities of > > `roff`, adding macros and traps and making it Turing-complete; this > > was `nroff`, which grew to become `troff` once the C/A/T typesetter > > was acquired. > > Yes. > > Here's what I have, though it looks better typeset[2]. Corrections from > witnesses are warmly welcomed. > > Name > roff - concepts and history of roff typesetting > > Description > The term roff describes a family of document formatting systems > known by names like troff, nroff, ditroff, and groff. A roff > system consists of an extensible text formatting language and a > set of programs for printing and converting to other text > formats. Unix-like operating systems often distribute a roff > system as a core package. > > [snip] > > History > Computer-driven document formatting dates back to the 1960s. The > roff system itself is intimately connected with the Unix > operating system, but its roots go back to the earlier operating > systems CTSS and Multics. > > The predecessor--RUNOFF > roff's ancestor RUNOFF was written in the MAD language by Jerry > Saltzer to prepare his Ph.D. thesis using the Compatible Time > Sharing System (CTSS), a project of the Massachusetts Institute > of Technology (MIT). The program is generally referred to in > full capitals, both to distinguish it from its many descendants, > and because bits were expensive in those days; five- and six-bit > character encodings were still in widespread usage, and mixed- > case alphabetics seen as a luxury. RUNOFF introduced a syntax of > inlining formatting directives amid document text, by beginning a > line with a period (an unlikely occurrence in human-readable > material) followed by a "control word". Control words with > obvious meaning like ".line length n" were supported as well as > an abbreviation system; the latter came to overwhelm the former > in popular usage and later derivatives of the program. A sample > of control words from a RUNOFF manual of December 1966 <http:// > web.mit.edu/Saltzer/www/publications/ctss/AH.9.01.html> was > documented as follows (with the parameter notation slightly > altered). The abbreviations will be familiar to roff veterans. > > Abbreviation Control word > .ad .adjust > .bp .begin page > .br .break > .ce .center > .in .indent n > .ll .line length n > .nf .nofill > .pl .paper length n > .sp .space [n] > > In 1965, MIT's Project MAC teamed with Bell Telephone > Laboratories and General Electric (GE) to inaugurate the Multics > <http://www.multicians.org> project. After a few years, Bell > Labs discontinued its participation in Multics, famously > prompting the development of Unix. Meanwhile, Saltzer's RUNOFF > proved influential, seeing many ports and derivations elsewhere. > > In 1969, Doug McIlroy wrote one such reimplementation of RUNOFF > in the BCPL language for a GE 645 running GECOS at the Bell Labs > location in Murray Hill, New Jersey. In its manual, the control > commands were termed "requests", their two-letter names were > canonical, and the control character was configurable with a .cc > request. Other familiar requests emerged at this time; no-adjust > (.na), need (.ne), page offset (.po), tab configuration (.ta, > though it worked differently), temporary indent (.ti), character > translation (.tr), and automatic underlining (.ul; on RUNOFF you > had to backspace and underscore in the input yourself). .fi to > enable filling of output lines got the name it retains to this > day. > > Unix and roff > roff was one of the first Unix programs. McIlroy's runoff was, > in Dennis Ritchie's term, "transliterated" from BCPL to DEC PDP-7 > assembly language for the fledgling Unix operating system. It > saw its name shortened to roff (perhaps under the influence of > Ken Thompson), while adding support for automatic hyphenation > with .hc and .hy requests; a generalization of line spacing > control with the .ls request; and what later roffs would call > diversions, with "footnote" requests. This roff indirectly > funded operating systems research at Murray Hill, for it was used > to prepare patent applications for AT&T to the U.S. government. > This arrangement enabled the group to acquire a PDP-11; roff > promptly proved equal to the task of typesetting the first > edition of the manual for what would later become known as "Unix > Version 1", dated November 1971. > > Output from all of the foregoing programs was limited to line > printers and paper terminals such the IBM 2471 (based on the > Selectric line of typewriters) and the Teletype Corporation Model > 37. Proportionally-spaced type was unknown. > > New roff and Typesetter roff > The first years of Unix were spent in rapid evolution. The > practicalities of preparing standardized documents like patent > applications (and Unix manual pages), combined with McIlroy's > enthusiasm for macro languages, perhaps created an irresistible > pressure to make roff extensible. Joe Ossanna's nroff, literally > a "new roff", was the outlet for this pressure. By the time of > Unix Version 3 (February 1973)--and still in PDP-11 assembly > language--it sported a swath of features now considered essential > to roff systems: definition of macros (.de), diversion of text > thence (.di), and removal thereof (.rm); trap planting (.wh; > "when") and relocation (.ch; "change"); conditional processing > (.if); and environments (.ev). Incremental improvements included > assignment of the next page number (.pn); no-space mode (.ns) and > restoration of vertical spacing (.rs); the saving (.sv) and > output (.os) of vertical space; specification of replacement > characters for tabs (.tc) and leaders (.lc); configuration of the > no-break control character (.c2); shorthand to disable automatic > hyphenation (.nh); a condensation of what were formerly six > different requests for configuration of page "titles" (headers > and footers) into one (.tl) with a length controlled separately > from the line length (.lt); automatic line numbering (.nm); > interactive input (.rd), which necessitated buffer-flushing > (.fl), and was made convenient with early program cessation > (.ex); source file inclusion in its modern form (.so; though > RUNOFF had an ".append" control word for a similar purpose) and > early advance to the next file argument (.nx); ignorable content > (.ig); and programmable abort (.ab). > > Third Edition Unix also brought the pipe(2) system call, the > explosive growth of a componentized system based around it, and a > "filter model" that remains perceptible today. Equally > importantly, the Bell Labs site in Murray Hill acquired a Graphic > Systems C/A/T phototypesetter, and with it came the necessity of > expanding the capabilities of a roff system to cope with > proportionally-spaced type, multiple type sizes, and a variety of > fonts. Ossanna wrote a parallel implementation of nroff for the > C/A/T, dubbing it troff (for "typesetter roff"). Unfortunately, > surviving documentation does not illustrate what requests were > implemented at this time for C/A/T support; the troff(1) man page > in Fourth Edition Unix (November 1973) does not feature a request > list, unlike nroff(1). Apart from typesetter-driven features, > Unix Version 4 roffs added string definitions (.ds); made the > escape character configurable (.ec); and enabled the user to > write diagnostics to the standard error stream (.tm). Around > 1974, empowered with multiple type sizes, italics, and a symbol > font specially commissioned by Bell Labs from Graphic Systems, > Brian Kernighan and Lorinda Cherry implemented eqn for > typesetting mathematics. In the same year, for Fifth Edition > Unix, Ossanna combined and reimplemented the two roffs in C, > using preprocessor conditions of that language to generate both > from a single source tree. > > Ossanna documented the syntax of the input language to the nroff > and troff programs in the "Troff User's Manual", first published > in 1976, with further revisions as late as 1992 by Kernighan. > (The original version was entitled "Nroff/Troff User's Manual", > which may partially explain why roff practitioners have tended to > refer to it by its AT&T document identifier, "CSTR #54".) Its > final revision serves as the de facto specification of AT&T > troff, and all subsequent implementors of roff systems have done > so in its shadow. > > A small and simple set of roff macros was first used for the > manual pages of Unix Version 4 and persisted for two further > releases, but the first macro package to be formally described > and installed was ms by Lesk in Version 6. He also wrote a > manual, "Typing Documents on the Unix System", describing ms and > basic nroff/troff usage, updating it as the package accrued > features. Sixth Edition additionally saw the debut of the tbl > preprocessor for formatting tables, also by Lesk. > > For Unix Version 7 (January 1979), McIlroy designed, implemented, > and documented the man macro package, introducing most of the > macros described in groff_man(7) today, and edited volume 1 of > the Version 7 manual using it. Documents composed using ms > featured in volume 2, edited by Kernighan. > > Ossanna had passed away unexpectedly in 1977, and after the > release of Version 7, with the C/A/T typesetter becoming > supplanted by alternative devices such as the Mergenthaler > Linotron 202, Kernighan undertook a revision and rewrite of troff > to generalize its design. To implement this revised > architecture, he developed the font and device description file > formats and the device-independent output format that remain in > use today. He described these novelties in the article "A > Typesetter-independent TROFF", last revised in 1982, and like the > troff manual itself, it is widely known by a shorthand, "CSTR > #97". > > Kernighan's innovations prepared troff well for the introduction > of the Adobe PostScript language in 1982 and a vibrant market in > laser printers with built-in interpreters for it. An output > driver for PostScript, dpost, was swiftly developed. However, > due to AT&T software licensing practices, Ossanna's troff, with > its tight coupling to the capabilities of the C/A/T, remained in > parallel distribution with device-independent troff throughout > the 1980s, leading some developers to contrive translators for > C/A/T-formatted documents to other devices. An example was > vtroff for Versatec and Benson-Varian plotters. Today, however, > all actively maintained troffs follow Kernighan's device- > independent design. > > Regards, > Branden > > [1] "The Evolution of the Unix Time-Sharing System", Ritchie, 1984 > [2] Formatted with: > groff -man -P-c -Tascii -rLL=72n -rHY=0 -dAD=l build/man/roff.7 > (The `AD` string is new to groff 1.23 man(7).) > [-- Attachment #2: Type: text/html, Size: 20167 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson ` (2 preceding siblings ...) 2022-01-12 22:32 ` Clem Cole @ 2022-01-13 2:38 ` John Labovitz 2022-01-13 7:42 ` Lars Brinkhoff 3 siblings, 1 reply; 102+ messages in thread From: John Labovitz @ 2022-01-13 2:38 UTC (permalink / raw) To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society On Jan 12, 2022, at 13:06, G. Branden Robinson <g.branden.robinson@gmail.com> wrote: > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Before RUNOFF was Peter Samson’s TJ-2 in 1963. It seems to have been the first program that incorporated the idea of input lines being interpreted as either control (with a prefix of a dot or other character) or text. I dug up this history when I wrote ‘The Electric Typesetter: The Origins of Computing in Typography’ for the American Printing History Association’s journal _Printing History_ (issue 21, 2017). Sadly they don’t have online archives; my PDF of the article is here: https://johnlabovitz.com/publications/The-electric-typesetter--The-origins-of-computing-in-typography.pdf It’s about more than markup languages, but here’s the relevant bit: > The earliest known text-formatting software, TJ-2, was created by MIT-trained computer scientist Peter Samson in 1963. Its design and architecture set the stage for text-formatting and typesetting programs for the next several decades. > > […] > > TJ-2 read lines of text as its input. Each line was collected and formatted to make justified paragraphs (of monospaced type). However, if a line started with a special control code (“overbar,” in the lingo of the PDP-1 system, its host computer), the program interpreted it as a command. There were only a few commands, including a primitive line-centering mode, some simplistic indentation, and a command that left a specific amount of vertical space for a figure (e.g., illustration) to be inserted later. > > […] > > Note that TJ-2 did not interface with a phototypesetter — or any typesetter. Its output was destined to be printed on what was essentially an automatic typewriter outfitted only with monospaced fonts. While this seems a limitation, perhaps it was a necessary constraint at the time. But the TJ-2 went on to inspire (directly or indirectly) a long branch of typesetting software beginning with RUNOFF (“A Right-Justifying Type Out Program”) in 1964, a program that used “control words scattered in the text [to] provide detailed control over the format” of text. RUNOFF substituted TJ-2’s proprietary “overbar” control code with a simple period, and expanded the set of commands to produce line and page breaks and folios (page numbers). Then, in a fairly confusing list of technical begats over a decade or so, RUNOFF (capitals) led to “runoff” (lowercase), then to “rf,” “roff,” “nroff,” and “troff” — all software programs that utilized the same basic idea as TJ-2. Links from the footnotes: TJ-2: http://www.dpbsmith.com/tj2.html RUNOFF: http://web.mit.edu/Saltzer/www/publications/CC-244.html Best, —John ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-13 2:38 ` John Labovitz @ 2022-01-13 7:42 ` Lars Brinkhoff 2022-01-13 13:47 ` John Labovitz 0 siblings, 1 reply; 102+ messages in thread From: Lars Brinkhoff @ 2022-01-13 7:42 UTC (permalink / raw) To: John Labovitz; +Cc: The Eunuchs Hysterical Society John Labovitz wrote: > The earliest known text-formatting software, TJ-2, was created by > MIT-trained computer scientist Peter Samson in 1963. I see claimed predecessors are JUSTIFY and TJ-1. How do you feel about those? ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] *roff history as told to GNU 2022-01-13 7:42 ` Lars Brinkhoff @ 2022-01-13 13:47 ` John Labovitz 0 siblings, 0 replies; 102+ messages in thread From: John Labovitz @ 2022-01-13 13:47 UTC (permalink / raw) To: Lars Brinkhoff; +Cc: The Eunuchs Hysterical Society On Jan 13, 2022, at 02:42, Lars Brinkhoff <lars@nocrew.org> wrote: > John Labovitz wrote: >> The earliest known text-formatting software, TJ-2, was created by >> MIT-trained computer scientist Peter Samson in 1963. > > I see claimed predecessors are JUSTIFY and TJ-1. How do you feel about > those? I’m sure I looked for TJ-1 when I did this research — an obvious question, given the ‘2’ suffix — but didn’t find anything then. I’m not familiar with JUSTIFY. Do you have links/info for those? —John ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole 2022-01-11 16:55 ` Richard Salz 2022-01-11 19:20 ` John Cowan @ 2022-01-12 8:48 ` arnold 2022-01-12 15:51 ` Larry McVoy 2022-01-12 15:56 ` Clem Cole 2 siblings, 2 replies; 102+ messages in thread From: arnold @ 2022-01-12 8:48 UTC (permalink / raw) To: lm, clemc; +Cc: tuhs, douglas.mcilroy Clem Cole <clemc@ccc.com> wrote: > Beyond base duplication, numerous companies published parts of them and in > particular parts if not all of the roff manual. For instance, a firm in > Seattle called CSSC published a number of reference guides and use guides > based on them You mean "SSC" - Specialized Systems Consultants. I did work for them in the 90s and they started Linux Journal, for which I wrote a few articles early on. The main guy there, Phil Hughes, was an interesting person. After getting rich from LJ he dropped out and moved to Central or South America. CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, Larry contributed. Arnold ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-12 8:48 ` [TUHS] Demise of TeX and groff (was: roff(7)) arnold @ 2022-01-12 15:51 ` Larry McVoy 2022-01-12 15:57 ` Clem Cole 2022-01-12 15:56 ` Clem Cole 1 sibling, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-12 15:51 UTC (permalink / raw) To: arnold; +Cc: tuhs, douglas.mcilroy On Wed, Jan 12, 2022 at 01:48:58AM -0700, arnold@skeeve.com wrote: > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > Larry contributed. Only in some very minor ways, the author and I chatted and I cleared up some of his thinking. With all due respect to him, I wasn't impressed with the source base, it was C++ (I think) and slow (I know). ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-12 15:51 ` Larry McVoy @ 2022-01-12 15:57 ` Clem Cole 0 siblings, 0 replies; 102+ messages in thread From: Clem Cole @ 2022-01-12 15:57 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs, douglas.mcilroy [-- Attachment #1: Type: text/plain, Size: 486 bytes --] On Wed, Jan 12, 2022 at 10:51 AM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Jan 12, 2022 at 01:48:58AM -0700, arnold@skeeve.com wrote: > > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > > Larry contributed. > > Only in some very minor ways, the author and I chatted and I cleared up > some of his thinking. With all due respect to him, I wasn't impressed > with the source base, it was C++ (I think) and slow (I know). > And IIRC, no man pages either ;-) [-- Attachment #2: Type: text/html, Size: 1067 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-12 8:48 ` [TUHS] Demise of TeX and groff (was: roff(7)) arnold 2022-01-12 15:51 ` Larry McVoy @ 2022-01-12 15:56 ` Clem Cole 1 sibling, 0 replies; 102+ messages in thread From: Clem Cole @ 2022-01-12 15:56 UTC (permalink / raw) To: arnold; +Cc: tuhs, douglas.mcilroy [-- Attachment #1: Type: text/plain, Size: 806 bytes --] Yes -- thank you. Dyslexia-r-me On Wed, Jan 12, 2022 at 3:49 AM <arnold@skeeve.com> wrote: > Clem Cole <clemc@ccc.com> wrote: > > > Beyond base duplication, numerous companies published parts of them and > in > > particular parts if not all of the roff manual. For instance, a firm in > > Seattle called CSSC published a number of reference guides and use guides > > based on them > > You mean "SSC" - Specialized Systems Consultants. I did work for them > in the 90s and they started Linux Journal, for which I wrote a few articles > early on. The main guy there, Phil Hughes, was an interesting person. > After getting rich from LJ he dropped out and moved to Central or South > America. > > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > Larry contributed. > > Arnold > [-- Attachment #2: Type: text/html, Size: 1345 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:42 ` Larry McVoy @ 2022-01-11 3:22 ` Adam Thornton 1 sibling, 0 replies; 102+ messages in thread From: Adam Thornton @ 2022-01-11 3:22 UTC (permalink / raw) To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: Computer Old Farts Followers Taking this to COFF... > On Jan 10, 2022, at 7:13 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote: > > Greg 'groggy' Lehey writes: > >> As long as man pages are formatted with ?roff, I don't see it going >> away. I don't suppose many people use troff any more, but there are >> enough of us, and as long as man pages stay the way they are, I don't >> think we're in any danger. > > Well there is mandoc(1). But as time goes by they just seem to be > re-implementing nroff. Of course that *must* be easier than just > learning n/troff in the first place :-P As someone who did a lot of a Ph.D. in the history of computing, and then went into IT because he liked eating protein sometimes: The great secret is that NO ONE EVER READS THE LITERATURE. We have now made all the mistakes at least four times: Once for each of mainframes, minis, micros, and mobile. You can be a rock star at any development or operations job, even if you are, like me, a Bear Of Little Brain, simply by having some idea of what was tried already to solve a problem like this, and why it didn't work. Which you can get by actually stopping to read up about your problem before diving headfirst into coding up a solution for it. If you happen to get stinking rich from this advice, you can buy me a bottle of whiskey sometime. Adam ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7)) 2022-01-11 1:59 ` [TUHS] Demise of " Greg 'groggy' Lehey 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-12 0:32 ` Nemo Nusquam 1 sibling, 0 replies; 102+ messages in thread From: Nemo Nusquam @ 2022-01-12 0:32 UTC (permalink / raw) To: tuhs On 2022-01-10 20:59, Greg 'groggy' Lehey wrote (in part): > As long as man pages are formatted with ?roff, I don't see it going > away. I don't suppose many people use troff any more, but there are > enough of us, and as long as man pages stay the way they are, I don't > think we're in any danger. Macos ships with *roff. N. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2021-12-31 23:40 ` Larry McVoy 2022-01-01 0:56 ` [TUHS] TeX and groff (was: roff(7)) Greg 'groggy' Lehey @ 2022-01-01 20:00 ` Jon Steinhart 2022-01-02 0:12 ` Larry McVoy 1 sibling, 1 reply; 102+ messages in thread From: Jon Steinhart @ 2022-01-01 20:00 UTC (permalink / raw) To: TUHS main list Larry McVoy writes: > On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: > > But macros aside, anyone who had used runoff had a > > massively simpler path into roff than TeX. My future was set. The phd > > students at Leeds looked down their noses at me for using cryptic .2 letter > > inline magic. They were the high priests of things, I was just a computer > > operator. Watching them spend weeks and weeks wrangling a one em offset > > problem stopping perfection in print was.. entertaining. > > I was program committee chair for Linux Expo in 1999 (all that means is > I formatted the proceedings into a book). I let people use LaTex but > encouraged troff. A few people tried out troff and their reaction was > "Wow, that was so easy and groff is really fast!" > > The only negative reaction was table of contents complaints, LaTex is > 2 pass so it can do them, roff is one pass so you have to fiddle with > things. A lot. > > I've used *roff for almost 40 years and I've never had the urge to use > something else. I wrote a paper a while back where they insisted on > LaTex and it just made me like *roff more. > > It's Betamax and VHS all over again, the crappy answer won. Happy New Year to everybody. COVID has taken its toll if people are spending New Year's Eve thinking about text formatting :-) Warning - this is a grumpy pendantic Jon post... First of all, I love *roff. It's the thing that got me started on UNIX when I needed to write documentation for my first summer project at BTL. There was a V3 UNIX machine across the hall from my lab (2C-517?) that I used for that. Been a fan ever since. Complaints about things like tables of contents are just that - complaints. C'mon - this is UNIX, composable software tools. So what if LaTex is 2 pass and *roff is 1 pass. I have a simple script and a Makefile that adds a 2nd pass and does all that. Even with that the LaTex ecosystem is way more complex than *roff. The one thing that *roff doesn't do which I think I remember from runoff is that runoff allowed in-line formatting requests; not just special escape sequences but everything. I never got into TeX although I've tried. Probably just first language syndrome. Coming from UNIX, I just find using \ as a non-escape character ugly, just like DOS\Windows pathnames. But there are a number of things that annoy me about it leading to the pendantic part. In my opinion, the big innovation in TeX is the two-dimensional layout. I do spend a bit of time on big documents adding keeps and such to avoid orphan and widow lines. In my opinion, much of what Don did in TeX added no value. Been meaning to ask him about it but with COVID haven't seen him in a while. For example, the language parsing broke no new ground. If it were me, and I wanted to explore/demo/implement two-dimensional layout, I would have added it to *roff. To me, the rest of it was not only a waste of time, but actually made the world worse by making two incompatible ways of doing things that practitioners have to learn instead of one. Make's life harder, not easier. How much time went into the development of the TeX front end that could have been done in a few hours had Don used lex/yacc? I made a similar comment to Alan Wirfs-Brock when proofreading his big 20th anniversary article on JavaScript. I don't get the "oooo, Eich did this one-week sprint to get a demo up and running" stuff. Had Eich used lex/yacc instead of rolling his own not only would he have not had to sprint, but we likely wouldn't still be fighting with optional semicolons decades later since that's harder to do with those tools. I read it as praising him for making a bad decision. This is my biggest issue with "modern software development". Seems like every project has to begin with it's own language, build system, package manager, and so on. Were I a modern software developer I'd create all that plus a new email client just to send this message :-) None of this behavior adds value. It makes it so that practitioners have to learn many arcane incompatible systems that all do pretty much the same thing. While I haven't given it a hard look, I'd look at the netstat/ss/... stuff with the same lens. Sure, new features were needed, but was it necessary to make the old stuff work differently? In my roll as a mentor, this is the stuff that freaks out students, especially during their first internships. I have to explain that there are two types of knowledge at play: their coursework and company crap. I tell them that they should be secure in the quality of their education and never ask their boss how to copy a string or something like that. But, it's perfectly OK to ask for help on the internal undocumented crufty development environment. In some respects, it's similar to how I decide what to bill for and what not to on consulting projects. I don't bill for learning some general knowledge thing that I didn't know. I do bill for learning odd project-specific weirdness that I'll never use on anything else. Back to *roff. Might have said this before, but pic is probably my favorite little language. It's like having an artist on staff because I can tell it what to draw and it will; I'm terrible at drawing. One of its best features that unfortunately was missed by the people who wrote fig is invisible objects. I typically start a figure with a big invisible box and hang things on it. If I need to move or scale things I just change the size of the box. Sure beats hours of carpal-tunnel clicking to move a pile of objects in a drawing program. I guess it's relative addressing versus absolute all over again; relative addressing makes it easier to relocate objects. One more way to look at this. I think that a lot depends on the state of the world when one starts using stuff. I remember a friend of mine telling me how much simpler DOS was as compared to UNIX. I told him that I thought that it was because he was growing up with DOS, and learned new features as they came along which is what I did with UNIX. By the the time he got started UNIX was more complicated. Of course, DOS caught up. It's sadly amusing how this applies to markup languages. People who carped about *roff requests are happy to craft HTML. I guess what's missing from the field is Lorites from Neal Stephenson's Anathem if you haven't read it. A priesthood who's role is to inform people claiming to invent something new that it's already been done. Jon ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-01 20:00 ` [TUHS] roff(7) [ and other related stuff ] Jon Steinhart @ 2022-01-02 0:12 ` Larry McVoy 2022-01-02 1:04 ` John Cowan 0 siblings, 1 reply; 102+ messages in thread From: Larry McVoy @ 2022-01-02 0:12 UTC (permalink / raw) To: Jon Steinhart; +Cc: TUHS main list On Sat, Jan 01, 2022 at 12:00:15PM -0800, Jon Steinhart wrote: > This is my biggest issue with "modern software development". Seems like every > project has to begin with it's own language, build system, package manager, > and so on. Were I a modern software developer I'd create all that plus a new > email client just to send this message :-) None of this behavior adds value. > It makes it so that practitioners have to learn many arcane incompatible > systems that all do pretty much the same thing. This. This is it. You and I must be the same kind of weird because when I wanted a scripting language that wasn't TCL weirdness, I had a compiler built that compiled stuff that so looked like C, I had a guy fix a bug in a patch that flew by. My big complaint with stuff like Rust, or even Go (sorry Rob), is that they picked a different syntax. Why not just use C syntax and extend it to do what you want? Why must every project redo everything. --lm who has moved to full on "Get off my lawn" ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 0:12 ` Larry McVoy @ 2022-01-02 1:04 ` John Cowan 2022-01-02 1:20 ` Larry McVoy 0 siblings, 1 reply; 102+ messages in thread From: John Cowan @ 2022-01-02 1:04 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 385 bytes --] On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote: > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > picked a different syntax. Why not just use C syntax and extend it to do > what you want? Why must every project redo everything. > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, extended to do what you wanted? [-- Attachment #2: Type: text/html, Size: 1018 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:04 ` John Cowan @ 2022-01-02 1:20 ` Larry McVoy 2022-01-02 1:47 ` Steve Nickolas ` (2 more replies) 0 siblings, 3 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-02 1:20 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote: > > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > > picked a different syntax. Why not just use C syntax and extend it to do > > what you want? Why must every project redo everything. > > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > extended to do what you wanted? I'm almost speechless. My progression was Basic, Pascal, C (and later Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like Rust, Go, D, and couldn't. If you think any of those other languages remotely approach the elegance of C, I just don't know what to say. C is beautiful, you look at the code and you can see what the hardware will be doing but it isn't assembler. It's what assembler wished it could be. It's the right mix of high enough that it works over all architectures and low enough that you see the hardware. You don't see the hardware with any of the other languages you listed. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:20 ` Larry McVoy @ 2022-01-02 1:47 ` Steve Nickolas 2022-01-02 2:12 ` Larry McVoy 2022-01-02 3:56 ` Jon Steinhart 2022-01-02 1:48 ` Jon Steinhart 2022-01-02 3:04 ` John Cowan 2 siblings, 2 replies; 102+ messages in thread From: Steve Nickolas @ 2022-01-02 1:47 UTC (permalink / raw) To: TUHS main list On Sat, 1 Jan 2022, Larry McVoy wrote: > On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > >> Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, >> extended to do what you wanted? > > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. Kinda sounds like me. Classic Microsoft BASIC, then QBASIC which was a mutant freak dialect with structs, functions and stuff... started learning C++ and then moved to C. I rarely use anything these days but C and once in a blue moon QBASIC for something quick and dirty. > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. This. I think it blends terseness, cleanness, simplicity and ease of use in just the right quantities in a way no language before or since has really been able to muster. Its only real weakness to me is that it isn't very good at string handling (the reason I sometimes kitbash stuff in BASIC still). -uso. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:47 ` Steve Nickolas @ 2022-01-02 2:12 ` Larry McVoy 2022-01-02 3:56 ` Jon Steinhart 1 sibling, 0 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-02 2:12 UTC (permalink / raw) To: Steve Nickolas; +Cc: TUHS main list On Sat, Jan 01, 2022 at 08:47:11PM -0500, Steve Nickolas wrote: > >If you think any of those other languages remotely approach the elegance > >of C, I just don't know what to say. > > This. > > I think it blends terseness, cleanness, simplicity and ease of use in just > the right quantities in a way no language before or since has really been > able to muster. Its only real weakness to me is that it isn't very good at > string handling (the reason I sometimes kitbash stuff in BASIC still). Function pointer decls drive me nuts. I agree with the string stuff, any scripting language handles that for you behind the scenes. C could add a String type that did all of that. We did that by hand in BitKeeper and it worked great, it is completely doable. All of the warts aside, you could take C and extend it to do a bunch of useful stuff and still have it be C. We tried with little-lang.org that is very C like but has almost all of the scripting goodness that tcl has exposed in a C like way. Check out the switch statement. Check out regexp. It's just part of the language, it is not function calls. Very pleasant and easy to use. little as a programming language is pretty dead, but as a proof of concept, it should be very much alive. If I had more money, cough, Rob, Google does, I'd fund a dialect of C that had all the C goodness and mixed in the right amount of scripting goodness. I'd come out of retirement to work on that. And I say that as this guy: http://mcvoy.com/lm/boat who is going out on the ocean tomorrow for crab. I love my retirement, I fish all the time, 60+ times per year, I'm really not interested in going back to work. But if someone threw a bunch of money at a team of people who wanted to make C as fun as Perl (or Python, I get it, Perl isn't cool any more but I loved the usefulness), I'd like to be Rob and Ken for that project, this is a giant overreach but I think I could bring taste to that project. If that ever happened, I think a lot of people on this list and elsewhere would like the result. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:47 ` Steve Nickolas 2022-01-02 2:12 ` Larry McVoy @ 2022-01-02 3:56 ` Jon Steinhart 1 sibling, 0 replies; 102+ messages in thread From: Jon Steinhart @ 2022-01-02 3:56 UTC (permalink / raw) To: TUHS main list I'm hoping that this doesn't devolved into another language preference war. What I really wanted to discuss was the nature of adding value and maybe nail down what's meant by value. The roffians versus the texans was just a good excuse. One example to me is that while it has it's own thing, perl packages are available via dnf/apt so one doesn't have to add extra steps to keep a system up to date. Things like pear and npm are negative value to me; they're an extra step. Maybe the mentality is that someone else maintains the system and they just maintain their little corner. My classic example is make. Works pretty well, was missing a few things that Sun and Gnu added later. The negative value stuff is [a-z]make, ninja, meson and all that. Does about the same stuff but in an incompatible way. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:20 ` Larry McVoy 2022-01-02 1:47 ` Steve Nickolas @ 2022-01-02 1:48 ` Jon Steinhart 2022-01-02 3:04 ` John Cowan 2 siblings, 0 replies; 102+ messages in thread From: Jon Steinhart @ 2022-01-02 1:48 UTC (permalink / raw) To: TUHS main list Larry McVoy writes: > On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > > On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote: > > > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > > > picked a different syntax. Why not just use C syntax and extend it to do > > > what you want? Why must every project redo everything. > > > > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > > extended to do what you wanted? > > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. > > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. > > C is beautiful, you look at the code and you can see what the hardware > will be doing but it isn't assembler. It's what assembler wished it > could be. It's the right mix of high enough that it works over all > architectures and low enough that you see the hardware. > > You don't see the hardware with any of the other languages you listed. I look at it slightly differently as the person who opened this particular can of worms. I'm not saying that the world should be fixed in stone; for example that there should never be another language because we already have one. I have trouble imagining how the features of C could be added to Fortran, Lisp, or Cobol in a reasonably compatible manner. And I have no issue with C not being an extension of an existing language even though it uses some of the features of other languages; to me C was the first non-clunky programming language. While I find C++ ugly, at least it uses C syntax where possible making it a reasonable transition for programmers. Going back to the original *roff discussion, I would have preferred to see a ".2D" request for *roff that added two-dimensional formatting. Guess what I'm saying is that I'm against change for the sake of change; I'm not against innovation. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 1:20 ` Larry McVoy 2022-01-02 1:47 ` Steve Nickolas 2022-01-02 1:48 ` Jon Steinhart @ 2022-01-02 3:04 ` John Cowan 2022-01-02 3:30 ` Warner Losh 2 siblings, 1 reply; 102+ messages in thread From: John Cowan @ 2022-01-02 3:04 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 707 bytes --] On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy <lm@mcvoy.com> wrote: > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. > > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. > Elegance? C? I think not. Lisp, _that's_ elegant. C is beautiful, you look at the code and you can see what the hardware > will be doing but it isn't assembler. Not really. You see what the hardware would be doing if it were a PDP-11. That's not the same thing at all. [-- Attachment #2: Type: text/html, Size: 1749 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) [ and other related stuff ] 2022-01-02 3:04 ` John Cowan @ 2022-01-02 3:30 ` Warner Losh 0 siblings, 0 replies; 102+ messages in thread From: Warner Losh @ 2022-01-02 3:30 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1249 bytes --] On Sat, Jan 1, 2022, 8:05 PM John Cowan <cowan@ccil.org> wrote: > > > On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy <lm@mcvoy.com> wrote: > > >> I'm almost speechless. My progression was Basic, Pascal, C (and later >> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then >> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like >> Rust, Go, D, and couldn't. >> >> If you think any of those other languages remotely approach the elegance >> of C, I just don't know what to say. >> > > Elegance? C? I think not. Lisp, _that's_ elegant. > LISP is all about the syntax. It was completely opaque until that moment when prefix notation clicked and it was all clear... C is beautiful, you look at the code and you can see what the hardware >> will be doing but it isn't assembler. > > > Not really. You see what the hardware would be doing if it were a PDP-11. > That's not the same thing at all. > Read the CHERI papers to find out that C is just doing approximately what you want / think is going on... unless you've been burned by UB that you thought you knew... At least compilers are getting stricter about flagging it, much to the annoyance of anybody with a code base more than a couple years old... Warner > [-- Attachment #2: Type: text/html, Size: 2906 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2021-12-31 23:07 ` George Michaelson 2021-12-31 23:40 ` Larry McVoy @ 2022-01-01 1:11 ` Phil Budne 2022-01-01 1:17 ` Chris Torek 2022-01-05 21:15 ` Tony Finch 2 siblings, 1 reply; 102+ messages in thread From: Phil Budne @ 2022-01-01 1:11 UTC (permalink / raw) To: tuhs > In 79-82 Runoff got me my undergraduate texts formatted on a dec10. > > Moving to work post degree on Unix and vms systems (my memory is that for > some reason VMS didn't have runoff) I had the Normalised "oh this must be > the same" hitting roff/nroff and got really confused by having both ms and > me macros. I similarly moved from the DEC 36-bit RUNOFF world. I was confused why anyone would need macros, until I typed in a paper, and didn't get any page numbers!! I'm 99.44% sure the VMS world got something called DSR (Digital Standard Runoff) at some point (likely written in BLISS). DEC-10/20 RUNOFF files did not always format correctly under DSR (DEC "standards" tended to be, the VMS team implements what they want, and they adjust the standard). I wondered about the RUNOFF/roff connection until I learned about CTSS, and was perplexed by IBM SCRIPT, which clearly had shared heritage, but didn't start with the letter r, but Wikipedia just told me: The origin of IBM's SCRIPT (markup) software began in 1968 when "IBM contracted Stuart Madnick of MIT to write a simple document preparation ..."[8] to run on CP/67.[9] He modeled it on MIT's CTSS RUNOFF.[10][11] So it must be true! Look at all the footnotes! But I was MOST perplexed when I was helping bring PDP-7 UNIX back up (I cobbled a replacement shell together), and found PDP-7 roff was as (or more) feeble than nroff without using a macro package (for fun, I tried writing some man pages, tho I was pretty sure on-line documentation didn't come about until PDP-11 days)), only without a macro facility! ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2022-01-01 1:11 ` [TUHS] roff(7) Phil Budne @ 2022-01-01 1:17 ` Chris Torek 2022-01-01 3:06 ` Larry McVoy 2022-01-01 3:34 ` George Michaelson 0 siblings, 2 replies; 102+ messages in thread From: Chris Torek @ 2022-01-01 1:17 UTC (permalink / raw) To: tuhs I actually strongly prefer TeX/LaTeX to *roff. But LaTeX does have its Knuthian and Stanfordish peculiarities. It helps if you read The TeXbook first and understand Tex's macro weirdness and \catcodes. Both systems have their blind spots. Ditroff fixes most of the big ones in nroff/troff, of course... Chris ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2022-01-01 1:17 ` Chris Torek @ 2022-01-01 3:06 ` Larry McVoy 2022-01-01 3:34 ` George Michaelson 1 sibling, 0 replies; 102+ messages in thread From: Larry McVoy @ 2022-01-01 3:06 UTC (permalink / raw) To: Chris Torek; +Cc: tuhs How does groff fair? On Fri, Dec 31, 2021 at 05:17:19PM -0800, Chris Torek wrote: > I actually strongly prefer TeX/LaTeX to *roff. But LaTeX does have > its Knuthian and Stanfordish peculiarities. It helps if you read > The TeXbook first and understand Tex's macro weirdness and \catcodes. > > Both systems have their blind spots. Ditroff fixes most of the > big ones in nroff/troff, of course... > > Chris -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2022-01-01 1:17 ` Chris Torek 2022-01-01 3:06 ` Larry McVoy @ 2022-01-01 3:34 ` George Michaelson 1 sibling, 0 replies; 102+ messages in thread From: George Michaelson @ 2022-01-01 3:34 UTC (permalink / raw) To: Chris Torek; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1015 bytes --] It's probable that I'm influenced by being an autodidact for the roff family and suffered "You're doing it wrong" disease from literate TeX users. Roff may be that kind of arcane evil we probably should eschew but it's morally closer to the typesetting machine. You tell it to select a reel of monotype font, move exactly (for this pointsize) some number of units and expose the mask to light at that point. It's a machine. TeX targeted a theoretically pure model of the world, and grudgingly admits the practicality of having to approximate the perfect line by some bezier curve, but why requires a phd in theoretical maths and there's a queue of art historians out the door who are holding golden proportions curves shouting "you're doing it wrong". TeX is a machine too but it's bytecode, not machinecode. I think I hurled "when are you implementing OSI" abuse at your talks in AUUG meetings Chris, if you'd replied "never" it would have been wiser than your more temperate "later" response as I recall it. [-- Attachment #2: Type: text/html, Size: 1311 bytes --] ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] roff(7) 2021-12-31 23:07 ` George Michaelson 2021-12-31 23:40 ` Larry McVoy 2022-01-01 1:11 ` [TUHS] roff(7) Phil Budne @ 2022-01-05 21:15 ` Tony Finch 2 siblings, 0 replies; 102+ messages in thread From: Tony Finch @ 2022-01-05 21:15 UTC (permalink / raw) To: TUHS main list In Cambridge there was a local roff-alike called GCAL that ran on Phoenix (the IBM mainframe). It was written by Philip Hazel, who went on to write Exim and PCRE. The Exim documentation and books were prepared using SGCAL, the Unix port of GCAL. (I don't know what the S stood for: son of? successor?) GCAL used roff-like initial-dot line commands. I found out recently that GCAL's name is also based on roff, and at the same time it followed Phoenix's bird-based naming scheme (eagle the scheduler, jackdaw the database system, pigeon the mailer). GCAL is short for geococcyx californianus, aka the roadrunner, which (after an encounter with a coyote) is known to run off. https://en.wikipedia.org/wiki/Phoenix_(computer) http://quercite.dx.am/ Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ East Sole, Lundy, Fastnet, Irish Sea: Variable 2 to 4 becoming southerly 6 to gale 8, perhaps severe gale 9 later in Irish Sea, veering westerly later. Slight or moderate, becoming rough or very rough in Lundy and Irish Sea, and very rough or high elsewhere. Rain or showers. Good, occasionally poor. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: [TUHS] Demise of TeX and groff (was: roff(7))
@ 2022-01-11 22:02 Douglas McIlroy
0 siblings, 0 replies; 102+ messages in thread
From: Douglas McIlroy @ 2022-01-11 22:02 UTC (permalink / raw)
To: TUHS main list
> Later Brian's work was updated after V7 and included some new tools, and became known as Writer's Workbench, which eventually was entered in the 'toolchest.'
WWB wouldn't exist if text had not routinely existed in
machine-readable form, thanks to word-processing. But the impetus for
WWB came from "style", not from troff.
Style was a spinoff of Lorinda Cherry's "parts", which assigned parts
of speech to the words of a document. Style provided a statistical
profile of the text: measures such as average word length: frequency
of passives, adjectives and compound sentences, reading level, etc.
WWB in turn offered writing advice based on such profiles.
Style was stimulated by Bill Vesterman, a professor of English at
Rutgers, who brought the idea to me. I introduced him to Lorinda, who
had it running in a couple of weeks. Then Nina McDonald at USG
conceived and packaged WWB as a distinct product, not just a
collection of entries in man 1.
Wikipedia reports a surmise that WWB sank out of sight because it was
not a standard part of Unix distributions.
Doug
^ permalink raw reply [flat|nested] 102+ messages in thread
end of thread, other threads:[~2022-01-23 22:27 UTC | newest] Thread overview: 102+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-31 15:47 [TUHS] roff(7) Douglas McIlroy 2021-12-31 23:07 ` George Michaelson 2021-12-31 23:40 ` Larry McVoy 2022-01-01 0:56 ` [TUHS] TeX and groff (was: roff(7)) Greg 'groggy' Lehey 2022-01-01 3:15 ` Larry McVoy 2022-01-10 19:00 ` Blake McBride 2022-01-10 20:21 ` Jon Forrest 2022-01-11 22:48 ` Blake McBride 2022-01-11 23:18 ` Larry McVoy 2022-01-12 1:19 ` Dave Horsfall 2022-01-12 1:46 ` Blake McBride 2022-01-12 2:12 ` Bakul Shah 2022-01-12 15:49 ` Larry McVoy 2022-01-12 16:22 ` Adam Thornton 2022-01-12 0:06 ` Jon Steinhart 2022-01-12 1:48 ` Blake McBride 2022-01-12 0:29 ` Nemo Nusquam 2022-01-12 1:53 ` Blake McBride [not found] ` <E3CC4B8A-4E88-4339-A4D3-4ED26BA80620@gmail.com> 2022-01-12 0:44 ` Jon Forrest 2022-01-12 2:00 ` Blake McBride 2022-01-12 2:10 ` David Arnold 2022-01-12 2:26 ` Adam Thornton 2022-01-12 19:54 ` John Cowan 2022-01-13 10:13 ` Thomas Paulsen 2022-01-13 20:00 ` John Cowan 2022-01-10 20:33 ` Larry McVoy 2022-01-10 20:37 ` Richard Salz 2022-01-10 21:04 ` Dan Cross 2022-01-10 21:48 ` Nemo Nusquam 2022-01-11 2:25 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:47 ` Larry McVoy 2022-01-22 2:34 ` [TUHS] troff environments, traps, and diversions (was: TeX and groff) Branden Robinson 2022-01-22 16:02 ` Douglas McIlroy 2022-01-23 19:45 ` Jon Steinhart 2022-01-23 22:26 ` Jon Steinhart 2022-01-11 1:52 ` [TUHS] Recognizing TeX (was: TeX and groff (was: roff(7))) Greg 'groggy' Lehey 2022-01-12 1:19 ` [TUHS] TeX and groff (was: roff(7)) Mary Ann Horton 2022-01-12 2:03 ` Blake McBride 2022-01-12 2:10 ` Bakul Shah 2022-01-12 3:44 ` Dan Cross 2022-01-12 16:48 ` Steffen Nurpmeso 2022-01-10 20:46 ` Steffen Nurpmeso 2022-01-11 1:59 ` [TUHS] Demise of " Greg 'groggy' Lehey 2022-01-11 2:13 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-01-11 2:42 ` Larry McVoy 2022-01-11 5:12 ` Greg 'groggy' Lehey 2022-01-11 5:59 ` John Labovitz 2022-01-11 8:57 ` arnold 2022-01-11 20:15 ` Jon Steinhart 2022-01-11 20:22 ` Larry McVoy 2022-01-11 20:26 ` Jon Steinhart 2022-01-11 20:36 ` Larry McVoy 2022-01-11 20:41 ` Jon Steinhart 2022-01-11 20:49 ` Larry McVoy 2022-01-11 21:03 ` Jon Steinhart 2022-01-11 8:50 ` arnold 2022-01-11 14:00 ` Larry McVoy 2022-01-12 23:22 ` [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) Greg 'groggy' Lehey 2022-01-12 23:29 ` Greg 'groggy' Lehey 2022-01-12 23:32 ` Larry McVoy 2022-01-11 15:47 ` [TUHS] Demise of TeX and groff (was: roff(7)) Clem Cole 2022-01-11 16:55 ` Richard Salz 2022-01-11 18:49 ` Clem Cole 2022-01-11 19:20 ` John Cowan 2022-01-11 20:06 ` Clem Cole 2022-01-11 23:57 ` Warner Losh 2022-01-12 0:03 ` Warner Losh 2022-01-12 8:54 ` arnold 2022-01-12 15:17 ` Clem Cole 2022-01-12 16:33 ` Dan Cross 2022-01-12 18:06 ` [TUHS] *roff history as told to GNU G. Branden Robinson 2022-01-12 18:34 ` Dan Halbert 2022-01-12 22:48 ` Clem Cole 2022-01-12 23:27 ` Charles H. Sauer 2022-01-13 0:35 ` Adam Thornton 2022-01-12 20:01 ` Dan Cross 2022-01-12 22:32 ` Clem Cole 2022-01-13 2:38 ` John Labovitz 2022-01-13 7:42 ` Lars Brinkhoff 2022-01-13 13:47 ` John Labovitz 2022-01-12 8:48 ` [TUHS] Demise of TeX and groff (was: roff(7)) arnold 2022-01-12 15:51 ` Larry McVoy 2022-01-12 15:57 ` Clem Cole 2022-01-12 15:56 ` Clem Cole 2022-01-11 3:22 ` Adam Thornton 2022-01-12 0:32 ` Nemo Nusquam 2022-01-01 20:00 ` [TUHS] roff(7) [ and other related stuff ] Jon Steinhart 2022-01-02 0:12 ` Larry McVoy 2022-01-02 1:04 ` John Cowan 2022-01-02 1:20 ` Larry McVoy 2022-01-02 1:47 ` Steve Nickolas 2022-01-02 2:12 ` Larry McVoy 2022-01-02 3:56 ` Jon Steinhart 2022-01-02 1:48 ` Jon Steinhart 2022-01-02 3:04 ` John Cowan 2022-01-02 3:30 ` Warner Losh 2022-01-01 1:11 ` [TUHS] roff(7) Phil Budne 2022-01-01 1:17 ` Chris Torek 2022-01-01 3:06 ` Larry McVoy 2022-01-01 3:34 ` George Michaelson 2022-01-05 21:15 ` Tony Finch 2022-01-11 22:02 [TUHS] Demise of TeX and groff (was: roff(7)) Douglas McIlroy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).