The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] roff(7)
@ 2021-12-31 15:47 Douglas McIlroy
  2021-12-31 23:07 ` George Michaelson
  0 siblings, 1 reply; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ messages in thread

* 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ 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; 104+ 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] 104+ messages in thread

* Re: [TUHS] roff(7) [ and other related stuff ]
  2022-01-02  4:02 [TUHS] roff(7) [ and other related stuff ] Noel Chiappa
@ 2022-01-02 10:46 ` markus schnalke
  0 siblings, 0 replies; 104+ messages in thread
From: markus schnalke @ 2022-01-02 10:46 UTC (permalink / raw)
  To: tuhs

Hoi.

[2022-01-01 23:02] jnc@mercury.lcs.mit.edu (Noel Chiappa)
>
>     > From: John Cowan
> 
>     > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax,
>     > extended to do what you wanted?
> 
> Why do all hammers look basically the same? Because there's an 'ideal
> hammer', and over time hammer design has asymtoted toward that 'ideal hammer'
> design.

Hammers don't look so much the same, except that each has a stick
and a head. Seems this example is a too simple one.

Saws for instance look quite differently, even within western
culture, but even more between western and japanese culture!


> So I suspect there is, to some degree, a Platonic 'ideal syntax' for a
> 'classic block-structured' programming language, and to me, C came pretty
> close to it.

I suspect that this assumption is limited to our programming
culture. We can hardly think outside of it. That's for the same
reason, Europeans did not create saws in Japanese style -- they
simply solved the same problems in a different way.

Thus I'd rather call it one of many possible good syntaxes for a
classic block-structured programming language ... and within our
culture about the best one.

But as well, in such views we obviously like to ignore the very
suboptimal `switch' (good for compilers; bad for programmers) and
the not so clean optional braces for single-statement blocks. C's
syntax is by no means as perfect, as we like to see it, but
nonetheless, it is very good. (And I like it a lot myself.)


Btw: With the rest of your message, I agree. Good that we're not
stuck with one syntax (and thus with one programming model)
forever. ;-)


meillo

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [TUHS] roff(7) [ and other related stuff ]
@ 2022-01-02  4:10 Douglas McIlroy
  0 siblings, 0 replies; 104+ messages in thread
From: Douglas McIlroy @ 2022-01-02  4:10 UTC (permalink / raw)
  To: TUHS main list

> Lisp, _that's_ elegant.

The machine shines through Lisp even more brightly than it does
through C. Lisp attains incredible power from a tiny base: car, cdr,
cons, cond, T, F, null, lambda, def, exuding elegance that survives
even in a raging sea of parentheses.

For Lisp-friendly applications nowadays, I prefer Haskell, which is
much further away from the machine. Haskell code approaches--and
sometimes surpasses--the cleanliness of good mathematical notation.
For string processing, I remember Snobol 3 with great fondness.

But for everyday work with arrays and numbers, C is the workhorse.
Still, I wish that C would evaluate comma expressions in parallel
rather than in series, as in (a,b) = (b,a).

Doug

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [TUHS] roff(7) [ and other related stuff ]
@ 2022-01-02  4:02 Noel Chiappa
  2022-01-02 10:46 ` markus schnalke
  0 siblings, 1 reply; 104+ messages in thread
From: Noel Chiappa @ 2022-01-02  4:02 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: John Cowan

    > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax,
    > extended to do what you wanted?

Why do all hammers look basically the same? Because there's an 'ideal
hammer', and over time hammer design has asymtoted toward that 'ideal hammer'
design. One can't just keep improving the design indefinitely - diminishing
returns set in.

So I suspect there is, to some degree, a Platonic 'ideal syntax' for a
'classic block-structured' programming language, and to me, C came pretty
close to it.

I except LISP from that assessment, because LISP is built around a
fundamentally different model of how computations/algorithms are organized,
and C and LISP aren't directly comparable.

But that realization points to a deeper bug with the 'Platonic ideal
language' concept above, which is that languages are fundamentally, albeit at
a very deep conceptual level, tied to the basic concept of the computing
hardware they are to run on. C/COBOL/FORTRAN/etc are all for von Neumann-like
(in a broad sense) computing engines - a single thread of computation, which
happens sequentially.

But we've pushed that paradigm about as far as it can go, we're into
diminishing returns territory on that one. The future, starting with the
hardware, will be very different - and will need quite different languages.
(Go, from what little I know of it, is a baby step in this direction - it is
intended to make it easy to use multiple simultaneous loci of execution,
making use of the mutiple cores that are common now.)

I suspect we'll be shifting to radically different paradigms, 50 years from
now - massively parallel computing meshes (think Connection Machines on
steroids - or the human brain), and those will use fundamentally different
computing paradigms, and programming languages for them, which in turn will
need very different syntax.

	Noel

^ permalink raw reply	[flat|nested] 104+ messages in thread

end of thread, other threads:[~2022-01-23 22:27 UTC | newest]

Thread overview: 104+ 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-02  4:02 [TUHS] roff(7) [ and other related stuff ] Noel Chiappa
2022-01-02 10:46 ` markus schnalke
2022-01-02  4:10 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).