[TUHS] Old troff files (1988-2007)

[TUHS] Old troff files (1988-2007)

[Jacobson, Doug W [E CPE] via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

Folks:

Long story short, I have a unpublished manuscript that a faculty member in my department wrote late 1980's early 2000's.  He did the entire thing in troff, eqn, and pic.
The faculty member is still alive.  A publisher is interested in the manuscript.  I have all of the source files on an old unix machine that still has troff, eqn and pic.  It also has groff.  This issue is that the pic commands are bracketed by .G1 and .G2 not .PS & .PE.  The original machine he would have used would have ran AT&T Sys V on an AT&T 3B20.  Below is one of the files.  Any thoughts on the .G1 .G2?  I can get the files that have only eqn and troff to create postscript, but the .G1/.G2 is not understood by pic.  I tried replacing the .G1/.G2 with .PS/PE and it failed.  I must be missing another program that uses the .G1/2

Thanks

.sp -3.5
.fp 1 Z
.fp 2 XI
.ps 11
.tl ' ' '1-10'
.EQ
delim $$
gsize 11
.EN

.po 0.9i
.vs 15
.G1
frame wid 5.7 ht 6.0 invis
coord x 0.2, 100 y -40, +22 log x
grid left from -30 to +20 by 10 ""
grid left from -40.04 to +19.96 by 10 ""
grid left from -39.96 to +20.04 by 10 ""
grid left from -39 to +22 by 1 ""
grid bot from 0.4 to 40 by *10 ""
grid bot from 1 to 100 by *10 ""
grid bot from 0.2 to 20 by *10 ""
grid bot from 0.3 to 30 by *10 ""
grid bot from 0.5 to 50 by *10 ""
grid bot from 0.6 to 60 by *10 ""
grid bot from 0.7 to 70 by *10 ""
grid bot from 0.8 to 80 by *10 ""
grid bot from 0.9 to 90 by *10 ""
ticks out left from -40 to +20 by 10
ticks out bot from 0.2 to 20 by *10
ticks out bot from 0.4 to 40 by *10
ticks out bot from 1 to 100 by *10
draw solid
  0.2 19.93
  2   19.93
  10  5.97
  100 -34.02
new solid
  0.2  20.07
  2    20.07
  10   6.05
  100  -33.95
new dotted
for i=0.45 to 23 by *1.05 do
{
  w=i*i
  f=200/sqrt(w*w+104*w+400)
  next at i,20*log(f)
}
label left "\u\udB \d\d"
label bot "\(*w,  rad/s"
.G2
.in 2
Fig. 1.4.  Graph of the magnitude in  dB  of  $H(s)~=~200 over{s sup 2~+~12^s~+~20}^,$$~s~=~j^omega$.

Doug Jacobson
University Professor, Dept. Electrical & Computer Engineering
Sunil & Sujata Gaitonde Professorship in Cybersecurity
Director: ISU Center for Cybersecurity Innovation and Outreach
Mail Address: 2520 Osborn Dr, 2215 Coover Hall
Iowa State University
PH: (515) 294-8307  Fax (515) 294-8432
Office: 371 Durham Hall
Center web site: http://www.cyio.iastate.edu/<https://urldefense.com/v3/__http:/www.cyio.iastate.edu/__;!!DZ3fjg!oVZir7OL4VMZHCYBX2CIbHyQTrepCPFkbLklXBKZNSZLWxcUR_aeyEMXUUmjHwkHNQ$>
Personal web site: http://www.dougj.net<https://urldefense.com/v3/__http:/www.dougj.net/__;!!DZ3fjg!oVZir7OL4VMZHCYBX2CIbHyQTrepCPFkbLklXBKZNSZLWxcUR_aeyEMXUUnkTUh6vg$>


[-- Attachment #2: Type: text/html, Size: 7083 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Doug, .G1/.G2 are bookmarks for the grap pre-processor.

--lyndon

[TUHS] Re: Old troff files (1988-2007)

[Jacobson, Doug W [E CPE] via TUHS]

Cool now I need to get grap running :)

Doug


-----Original Message-----
From: Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> 
Sent: Friday, October 4, 2024 4:51 PM
To: Jacobson, Doug W [E CPE] <dougj@iastate.edu>; tuhs@tuhs.org
Subject: Re: [TUHS] Old troff files (1988-2007)

Doug, .G1/.G2 are bookmarks for the grap pre-processor.

--lyndon

[TUHS] Re: Old troff files (1988-2007)

[Bakul Shah via TUHS]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

It's in plan9port.

https://github.com/9fans/plan9port

> On Oct 4, 2024, at 2:52 PM, Jacobson, Doug W [E CPE] via TUHS <tuhs@tuhs.org> wrote:
> 
> Cool now I need to get grap running :)
> 
> Doug
> 
> 
> -----Original Message-----
> From: Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> 
> Sent: Friday, October 4, 2024 4:51 PM
> To: Jacobson, Doug W [E CPE] <dougj@iastate.edu>; tuhs@tuhs.org
> Subject: Re: [TUHS] Old troff files (1988-2007)
> 
> Doug, .G1/.G2 are bookmarks for the grap pre-processor.
> 
> --lyndon


[-- Attachment #2: Type: text/html, Size: 988 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

There part of heirloom troff distribution and are likely to just work on a
modern Unix

https://n-t-roff.github.io/heirloom/doctools.html


Sent from a handheld expect more typos than usual


On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS <
tuhs@tuhs.org> wrote:

> Cool now I need to get grap running :)
>
> Doug
>
>
> -----Original Message-----
> From: Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>
> Sent: Friday, October 4, 2024 4:51 PM
> To: Jacobson, Doug W [E CPE] <dougj@iastate.edu>; tuhs@tuhs.org
> Subject: Re: [TUHS] Old troff files (1988-2007)
>
> Doug, .G1/.G2 are bookmarks for the grap pre-processor.
>
> --lyndon
>

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Btw. The heirloom version of troff is from Solaris SVR4 which should be
quite close the version from the 3B20

Sent from a handheld expect more typos than usual


On Fri, Oct 4, 2024 at 7:01 PM Clem Cole <clemc@ccc.com> wrote:

> There part of heirloom troff distribution and are likely to just work on a
> modern Unix
>
> https://n-t-roff.github.io/heirloom/doctools.html
>
>
> Sent from a handheld expect more typos than usual
>
>
> On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS <
> tuhs@tuhs.org> wrote:
>
>> Cool now I need to get grap running :)
>>
>> Doug
>>
>>
>> -----Original Message-----
>> From: Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>
>> Sent: Friday, October 4, 2024 4:51 PM
>> To: Jacobson, Doug W [E CPE] <dougj@iastate.edu>; tuhs@tuhs.org
>> Subject: Re: [TUHS] Old troff files (1988-2007)
>>
>> Doug, .G1/.G2 are bookmarks for the grap pre-processor.
>>
>> --lyndon
>>
>

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

Hi Doug,

At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote:
> Folks:
> 
> Long story short, I have a unpublished manuscript that a faculty
> member in my department wrote late 1980's early 2000's.  He did the
> entire thing in troff, eqn, and pic.  The faculty member is still
> alive.  A publisher is interested in the manuscript.  I have all of
> the source files on an old unix machine that still has troff, eqn and
> pic.  It also has groff.  This issue is that the pic commands are
> bracketed by .G1 and .G2 not .PS & .PE.

As others noted, those are the characteristic preprocessor tokens used
by grap(1).

groff(1) says:
     A free implementation of the grap preprocessor, written by Ted
     Faber ⟨faber@lunabase.org⟩, can be found at the grap website
     ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩.  groff
     supports only this grap.

Distributors often have a package of Faber's grap.  I'm not aware of any
other in circulation.  (Happy to be corrected here.)

Please contact the groff list, groff at gnu dot org, if you have any
problems using it to format these documents and/or to note formatting
discrepancies between Unix troff and groff.  There will likely be some.

I've noted differences between DWB troff and Heirloom troff, so using
the latter does not guarantee identical rendering, and moreover
DWB/System V troff has some bugs/limitations that Heirloom and/or GNU
troffs have fixed, and some of these can affect formatting.

Here's a list from groff's tbl(1) man page, for example.

   GNU tbl enhancements
     In addition to extensions noted above, GNU tbl removes constraints
     endured by users of AT&T tbl.

     •  Region options can be specified in any lettercase.

     •  There is no limit on the number of columns in a table,
        regardless of their classification, nor any limit on the number
        of text blocks.

     •  All table rows are considered when deciding column widths, not
        just those occurring in the first 200 input lines of a region.
        Similarly, table continuation (.T&) tokens are recognized
        outside a region’s first 200 input lines.

     •  Numeric and alphabetic entries may appear in the same column.

     •  Numeric and alphabetic entries may span horizontally.

One can imagine how a 200+-row table could format differently between
DWB/System V and GNU tbl, without either being "wrong".

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Peter Yardley]

This isn’t helpful, but the .G1 .G2 look a lot like Gerber codes used in NC machine tools. 

Sent from my iPhone

> On 5 Oct 2024, at 1:52 pm, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> 
> Hi Doug,
> 
> At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote:
>> Folks:
>> 
>> Long story short, I have a unpublished manuscript that a faculty
>> member in my department wrote late 1980's early 2000's.  He did the
>> entire thing in troff, eqn, and pic.  The faculty member is still
>> alive.  A publisher is interested in the manuscript.  I have all of
>> the source files on an old unix machine that still has troff, eqn and
>> pic.  It also has groff.  This issue is that the pic commands are
>> bracketed by .G1 and .G2 not .PS & .PE.
> 
> As others noted, those are the characteristic preprocessor tokens used
> by grap(1).
> 
> groff(1) says:
>     A free implementation of the grap preprocessor, written by Ted
>     Faber ⟨faber@lunabase.org⟩, can be found at the grap website
>     ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩.  groff
>     supports only this grap.
> 
> Distributors often have a package of Faber's grap.  I'm not aware of any
> other in circulation.  (Happy to be corrected here.)
> 
> Please contact the groff list, groff at gnu dot org, if you have any
> problems using it to format these documents and/or to note formatting
> discrepancies between Unix troff and groff.  There will likely be some.
> 
> I've noted differences between DWB troff and Heirloom troff, so using
> the latter does not guarantee identical rendering, and moreover
> DWB/System V troff has some bugs/limitations that Heirloom and/or GNU
> troffs have fixed, and some of these can affect formatting.
> 
> Here's a list from groff's tbl(1) man page, for example.
> 
>   GNU tbl enhancements
>     In addition to extensions noted above, GNU tbl removes constraints
>     endured by users of AT&T tbl.
> 
>     •  Region options can be specified in any lettercase.
> 
>     •  There is no limit on the number of columns in a table,
>        regardless of their classification, nor any limit on the number
>        of text blocks.
> 
>     •  All table rows are considered when deciding column widths, not
>        just those occurring in the first 200 input lines of a region.
>        Similarly, table continuation (.T&) tokens are recognized
>        outside a region’s first 200 input lines.
> 
>     •  Numeric and alphabetic entries may appear in the same column.
> 
>     •  Numeric and alphabetic entries may span horizontally.
> 
> One can imagine how a 200+-row table could format differently between
> DWB/System V and GNU tbl, without either being "wrong".
> 
> Regards,
> Branden

[TUHS] Re: Old troff files (1988-2007)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

Branden. Thank you.     FWIW I have generally found heirloom to be good
enough for rendering most old troff on modern systems such that I can
reasonably read the text.  But I suspect your detail is useful to know in
some cases.  As they say YMMR.  That said I often use the groff tools kits
since it’s what comes with things like brew on my Mac but it burps on
certain macros, particularly when I want to render old man pages or doc
files from old Unix versions  with things like .UX macro (which is a PITA).

Thanks again,
Clem

Sent from a handheld expect more typos than usual


On Fri, Oct 4, 2024 at 8:14 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Hi Doug,
>
> At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote:
> > Folks:
> >
> > Long story short, I have a unpublished manuscript that a faculty
> > member in my department wrote late 1980's early 2000's.  He did the
> > entire thing in troff, eqn, and pic.  The faculty member is still
> > alive.  A publisher is interested in the manuscript.  I have all of
> > the source files on an old unix machine that still has troff, eqn and
> > pic.  It also has groff.  This issue is that the pic commands are
> > bracketed by .G1 and .G2 not .PS & .PE.
>
> As others noted, those are the characteristic preprocessor tokens used
> by grap(1).
>
> groff(1) says:
>      A free implementation of the grap preprocessor, written by Ted
>      Faber ⟨faber@lunabase.org⟩, can be found at the grap website
>      ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩.  groff
>      supports only this grap.
>
> Distributors often have a package of Faber's grap.  I'm not aware of any
> other in circulation.  (Happy to be corrected here.)
>
> Please contact the groff list, groff at gnu dot org, if you have any
> problems using it to format these documents and/or to note formatting
> discrepancies between Unix troff and groff.  There will likely be some.
>
> I've noted differences between DWB troff and Heirloom troff, so using
> the latter does not guarantee identical rendering, and moreover
> DWB/System V troff has some bugs/limitations that Heirloom and/or GNU
> troffs have fixed, and some of these can affect formatting.
>
> Here's a list from groff's tbl(1) man page, for example.
>
>    GNU tbl enhancements
>      In addition to extensions noted above, GNU tbl removes constraints
>      endured by users of AT&T tbl.
>
>      •  Region options can be specified in any lettercase.
>
>      •  There is no limit on the number of columns in a table,
>         regardless of their classification, nor any limit on the number
>         of text blocks.
>
>      •  All table rows are considered when deciding column widths, not
>         just those occurring in the first 200 input lines of a region.
>         Similarly, table continuation (.T&) tokens are recognized
>         outside a region’s first 200 input lines.
>
>      •  Numeric and alphabetic entries may appear in the same column.
>
>      •  Numeric and alphabetic entries may span horizontally.
>
> One can imagine how a 200+-row table could format differently between
> DWB/System V and GNU tbl, without either being "wrong".
>
> Regards,
> Branden
>

[-- Attachment #2: Type: text/html, Size: 4228 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 4108 bytes --]

Hi Clem,

At 2024-10-05T09:14:27-0400, Clem Cole wrote:
> Branden. Thank you.     FWIW I have generally found heirloom to be
> good enough for rendering most old troff on modern systems such that I
> can reasonably read the text.

I generally get good results with it as well.  I frequently compare the
behaviors of DWB 3.3 troff and Heirloom troff with 2-3 versions of GNU
troff (1.22.4 [2018], 1.23.0 [2023], and bleeding-edge development).

Setting aside the issue of extensions (whether to the *roff language, to
preprocessors, or to macro packages), I find that Heirloom fixes many
DWB bugs.  I think GNU troff can boast of slightly better terminal
support, although nroff veterans are sometimes scandalized by GNU
troff's terminal output driver (grotty(1)) assuming that it's _not_
talking to a Teletype Model 37, but rather a more-or-less ECMA-48 video
terminal.

To brutally abbreviate the history, for $reasons Unix nroff got frozen
in amber in 1978 with respect to terminal support, and continues to live
in a world where the termcap and terminfo libraries were never written.
Unfortunately, the maintainer of the less(1) pager still presumes
(prefers?) that world.

A previous groff maintainer observed that few of our users operate paper
terminals.  (Nevertheless grotty retains support for them with its `-c`
option.)

Anton Shepelev wrote a summary I find admirably concise and blunt:

"`grotty' is not an appendix to a pager, but a program for printing
direct to the terminal.  Most terminals support those basic ANSI
control sequences, and many console programs freely use them.  If a
pager cannot transparently forward them to the terminal, it is a
problem of the pager, not of `grotty', and having a broken -man
configuration by default to just to appease `less' is stupid."

> That said I often use the groff tools kits since it’s what comes with
> things like brew on my Mac but it burps on certain macros,
> particularly when I want to render old man pages or doc files from old
> Unix versions  with things like .UX macro (which is a PITA).

Yes.  Our ms(7) manual ("ms.ms"), originally by Larry Kollar, concedes
its limitations.

--- snip ---
7.1.  Unix Version 7 ms macros not implemented by groff ms

Several macros described in the Unix  Version  7  ms  documentation  are
unimplemented  by groff ms because they are specific to the requirements
of documents produced internally by Bell  Laboratories,  some  of  which
also  require  a glyph for the Bell System logo that groff does not sup‐
port.  These macros implemented several document type formats  (EG,  IM,
MF,  MR,  TM,  TR),  were meaningful only in conjunction with the use of
certain document types (AT, CS, CT, OK, SG), stored the postal addresses
of Bell Labs sites (HO, IH, MH, PY, WH), or lacked a  stable  definition
over  time  (UX).   To  compatibly  render historical ms documents using
these macros, we advise your documents to invoke the rm request  to  re‐
move  any  such  macros it uses and then define replacements with an au‐
thentically  typeset original at hand.[10] For informal purposes, a sim‐
ple definition of UX should maintain the readability of  the  document’s
substance.

                           ┌───────────────┐
                           │ .rm UX        │
                           │ .ds UX Unix\" │
                           └───────────────┘

───────────
  [10] The removal beforehand is  necessary  because  groff  ms  aliases
these macros to a diagnostic macro, and you want to redefine the aliased
name, not its target.
--- end snip ---

The point of the `UX` macro was to abstract away the problem of sticking
a footnote at the bottom of the page to acknowledge (or in the Labs'
case, announce) the holder of the Unix trade mark on its first
occurrence.

I suspect the CSRC did not anticipate that the trade mark would ever
change hands, let alone how many times...

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Why groff ms doesn't completely support historical documents

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3750 bytes --]

Someone on the TUHS list mailed me privately, prompting me to
write this lengthy apology (in the classical sense) of why groff doesn't
make a certain application easier.  I have slightly revised my response.

This message also may serve as a summary of the challenges that need to
be overcome if someone else wants to tackle the job, and potentially
contribute it to groff.

[person creates PDFs of historical Unix documents (many of which are
written using the ms macros) and wishes groff ms made the task easier]

I sympathize.  I sometimes render historical documents, so I prescribed
in groff ms's documentation the approach that I take myself.  I decided
against trying to support a "-matt" or "-msatt" option in groff because
it's flatly impossible to know which definition of `UX` to use.  Even a
date declaration in the document sheds little light, as we then have to
consider the question of whether we want fidelity to the actual state of
the mark at the time of that declared date, or to what would have been
rendered in the author's environment--and they may have been using an ms
that wasn't "up to date" in the same respect.  That information, too, is
not recorded in the document.[1]

Providing all the macros _except_ `UX` didn't seem likely to satisfy
users since that's the most important one!  It shows up in body text
whereas all the others seldom do--if you can live without the cover page
then, often, you're golden.  Except for `UX`.

Finally there is the name collision problem with Berkeley.  4.2BSD and
later ms defined `CT` and `TM` macros (aspects of their "thesis mode")
and once again there's no declarator within the document to tell you
which dialect of ms is in use.  This one can be heuristically figured
out with pretty good odds, I suspect, but troff works as a filter--what
was I going to do, write a preprocessor just for this?

(Hmm, maybe grog(1) could do it, and that would be in its wheelhouse.
But there's no point until and unless we reimplement support for
Berkeley thesis mode in the first place [so that grog has an option
argument to report], and that is an undertaking I have demurred.[2])

It seemed like a moderate amount of work for almost zero upside.  It's
also hard to validate/verify my work.  The only historical troffs to
which I have access are Seventh Edition Unix troff (1979, before
Kernighan) and DWB 3.3 (early 1990s).  It's a right pain in the butt to
inspect typesetter output on V7 because I have nothing that emulates a
C/A/T or translates it to device-independent troff output for a
"ditroff"-style device description that Kernighan troff, DWB/Hierloom
Doctools troff, or GNU troff could use.

And even if I had either of those, they'd have to be vetted to a _high_
degree of quality before they'd be fit for purpose; else I wouldn't know
whether I was chasing bugs in the groff ms macros or the C/A/T
emulator/translator.

So, to summarize, I confine my compatibility efforts to _nroff_ output,
and rule the Bell Labs "site" macros out of scope.  I feel there is not
much more I can do, and have confidence my results, without resources
that I'm lacking.

I hope this sheds some light on my reasoning.

Regards,
Branden

[1] Still, if someone wants to start, I'd start here.

    https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/ms/tmac.s

[2] One person, ever, has requested it, 20 years ago.  And I have no
    specimens of input or corresponding model output rendered by an
    "authentic" BSD troff [formatter executable PLUS support files]
    against which to develop a reconstruction.  (On the bright side, the
    Berkeley modifications to the once-encumbered AT&T "tmac.s" are, of
    themselves, presumably BSD-licensed.)

    https://savannah.gnu.org/bugs/?64455

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Jaap Akkerhuis]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]



> On 6 Oct 2024, at 00:22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> 
> Unix nroff got frozen
> in amber in 1978 with respect to terminal support, and continues to live
> in a world where the termcap and terminfo libraries were never written.

Nroff did actually read in the output description from, if I remember
correctly, /usr/lib/termtab/xxx with the argument -Txxx.  these where
stripped object files. I have made them for Diable daisy-wheel printers.  Some
could create bold characters by overprinting and we once had one with two
print heads, the second head had an italics daisy-wheel mounted.

	jaap


[-- Attachment #2: Type: text/html, Size: 2893 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3640 bytes --]

Hi Jaap,

At 2024-10-06T14:54:59+0200, Jaap Akkerhuis wrote:
> > On 6 Oct 2024, at 00:22, G. Branden Robinson
> > <g.branden.robinson@gmail.com> wrote:
> > 
> > Unix nroff got frozen in amber in 1978 with respect to terminal
> > support, and continues to live in a world where the termcap and
> > terminfo libraries were never written.
> 
> Nroff did actually read in the output description from, if I remember
> correctly, /usr/lib/termtab/xxx with the argument -Txxx.

Yes.  When Kernighan refactored V7 troff/nroff for device-independence,
he implemented a similar scheme for each.  While for troff, this
resulted in device and font description files, "DESC" and a motley
variety of capitalized one-or-two letter names for fonts, for nroff they
were termed "driving tables", a terminological choice that concealed how
closely they resembled the troff scheme.

Compare, for example:

https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/DESC
https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/R

with:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.37
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.450

...and the family resemblance seems clear.

> these where stripped object files.

I have heard tell of a "binary format" for Kernighan troff device and
font descriptions but never encountered it.  groff never attempted to
replicate it and I gather that Plan 9 troff also discarded it.

> I have made them for Diable daisy-wheel printers.  Some could create
> bold characters by overprinting and we once had one with two print
> heads, the second head had an italics daisy-wheel mounted.

Right.  The Diablo features heavily in early '80s Unix documentation.

However none of this has much to do, in my opinion, with the _terminal
capability databases_ offered by termcap and (later) terminfo.  The
whole point of these is to _query_ the user's terminal type, not have to
be told it with some `-T` option.

To my knowledge, no nroff has ever simply looked at "$TERM" and then
decided how to format output.  Approximately all other Unix software
that writes to a terminal behaves that way.  nroff didn't, and by God
some Unix grognards would have it stay that way.[1][2]  Mark Nudelman's
less(1) is probably the foremost contributor of inertia here, since
man(1) is far and away the leading application of nroff(1), and less(1)
the victorious pager program after a long and bloody campaign of
attrition.  (This isn't a complaint; we could have done worse.  most(1)
could have won instead.[3])

Lennart Jablonka has contributed a patch to groff to resolve this
longevous discrepancy.  (It ended up on my slow path for integration
because I decided I needed to understand terminfo much better, and that
in turn led me to contribute a large volume of man page revisions to
ncurses, many of which can be enjoyed(?) in its 6.5 release.[4])

https://savannah.gnu.org/bugs/?63583

Regards,
Branden

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312935
[2] https://unix.stackexchange.com/questions/729124/linux-9-commands-send-ansi-color-sequences-to-monochrome-terminal
[3] https://invisible-island.net/ncurses/ncurses-slang.html

[4] https://invisible-island.net/ncurses/announce.html
    https://invisible-island.net/ncurses/man/

    Despite his grognard standpoint with respect to grotty(1)'s default
    use of SGR escape sequences in output, I would emphasize that Thomas
    Dickey has been a pleasure to work with.  It's difficult to imagine
    the same being true of Alan Curry.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Ron Natalie]

For years JHU had a KSR37 with a Greek box and nroff drove it direcly 
sending all those ESC-8 and ESC-9 things.   There were some output 
filters that converted this to things like the Diablo daisy wheels and 
even the rather crude dot matrix lineprinter we had.
Eventually, George Toth, one of our programmers came up with the idea of 
building a C/A/T simulator.    He went to the Naval Research Lab and 
printed out a full typeface on film from their CAT.  He then cut them 
out and glued them to the front of an oscilliscope, one letter at a 
time.
There was a PDP-11/20 that ran a Scanning Transmission Electron 
Microscope (at the time one of the few in captivity).   He would take 
the scanning driver cables from the microscope and put them on the X/Y 
of the oscilliscope and then took the sense wire and put it on a 
photomultiplier tube that was mounted in a scope camera.   He then fired 
up the (DOS/BATCH) microscope software to tell it to do a scan.    He’d 
then swap the RK05 packs and bring up Minunix and read his scanned 
character out of the frame buffer.

One character at a time he accumulated an entire Roman, Bold, Italic, 
and Symbol set.    He wrote the emulator and we could TROFF through his 
software to the Versatec lineprinter we had.    The chemicals from those 
printers makes my skin break out just thinking about it.   It was the 
only printer we had at BRL for political reasons for quite a while.   It 
also would eat the ink of the government issued (made oddly by a 
workshop for the blind) pens.

-Ron

[TUHS] Re: Old troff files (1988-2007)

[Ron Natalie]

I got a chuckle because apparently an old quote of mine is enshrined in 
the GROFF documentation (under the debugging section):

Standard troff voodoo, just put a power of two backslashes in front of 
it until it works and if you still have problems add a \c. — Ron Natalie

Thanks, G. Branden Robinson, for calling it to my attention.

More nroff fun and games:   My first job out of college was working on a 
restricted government project on RSX-11/M.    I’d been doing various 
UNIX and n/troff stuff for years at JHU.
The QA people decided to go all PWB on this project using SCCS etc…     
I knew that Denis Mumaugh at the NSA had written nroff macros to do 
classification markings automatically.
I asked for a copy, but he couldn’t figure out how to get a tape to me.  
  I reimplemented it myself.   Originally, I had the idea of processing 
each marked paragraph into a diversion but
that was problematic.   I then just output the footer and then “reverse 
fed” the paper back to the top to add the top classification.   Of 
course, you had to run your nroff via col to
get it to print right.

I also fixed the line printer spooler to catch classification markings 
and mark them  pages appropriately as well.    All this I did while 
waiting the 11 months for my ‘beyond TS’ clearance to arrive.
Seems like everybody on the project failed their polygraph the first 
time.  Examiner must have had a hard seat on the bus from the east 
coast.

This was also the project where I had this exchange:

Bernie:   What’s all this Bell System crud in the editor?
Me:   It’s UNIX.   It’s all Bell System crud.

I walk around to his terminal and see this:

$ 1
One Bell System.  It works.
$ 1
One Bell System.   It works.

Me:    You’re not in the editor,  Bernie.

After that the /usr/bin/1 command was changed to

echo “You’re not in the editor, Bernie.”

[TUHS] Re: Old troff files (1988-2007)

[Leah Neukirchen]

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

> Anton Shepelev wrote a summary I find admirably concise and blunt:
>
> "`grotty' is not an appendix to a pager, but a program for printing
> direct to the terminal.  Most terminals support those basic ANSI
> control sequences, and many console programs freely use them.  If a
> pager cannot transparently forward them to the terminal, it is a
> problem of the pager, not of `grotty', and having a broken -man
> configuration by default to just to appease `less' is stupid."

I don't see the problem, less supports -R for the last 25 years...

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

[TUHS] Re: Old troff files (1988-2007)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Hi Leah,

At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote:
> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
> > Anton Shepelev wrote a summary I find admirably concise and blunt:
> >
> > "`grotty' is not an appendix to a pager, but a program for printing
> > direct to the terminal.  Most terminals support those basic ANSI
> > control sequences, and many console programs freely use them.  If a
> > pager cannot transparently forward them to the terminal, it is a
> > problem of the pager, not of `grotty', and having a broken -man
> > configuration by default to just to appease `less' is stupid."
> 
> I don't see the problem, less supports -R for the last 25 years...

Yeah.  People's ire seems to rise from the fact that grotty's default is
to assume SGR support and less's default is to not interpret SGR.

I would prefer that `-R` were less's default; that would better serve
the larger proportion of ECMA-48 video terminals using the pager versus
those using it with (an emulator of) hardcopy terminals.

Whatever transition process needs to commence for that to happen, I
think it should.

But in the meantime it's no great effort for me (nor for most people) to
alias 'less' to 'less -R', write a shell function to do similarly, or
just type three more characters.

(For those requiring accessibility assistance, shell aliases and
functions, programmable key bindings, and similar should serve as they
do the merely impatient.)

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Jacobson, Doug W [E CPE] via TUHS]

Hello group:

BTW:, I love all the comments and discussions this started.

Using Groff (eqn+pic) + grap I was able to create a PDF of the book.  It took about 8 hours part of which was figuring out the syntax differences. He had divided the book up into a file for each page or two, so 100+ files.  I think he did that, so he did not waste paper since he had to print out the pages to see if they looked right, no display to view them. It was not perfect but is good enough for the publisher to review.  The book is on filters (EE book) and is full of graphs, circuits, and equations.  He used pic to draw the circuits, which was amazing.  This was fun to take a forgotten manuscript written by a colleague and with luck maybe getting it published while he is still alive.  If the publisher wants to publish it, I'm not sure how they will handle troff files :) 

Doug

-----Original Message-----
From: G. Branden Robinson <g.branden.robinson@gmail.com> 
Sent: Tuesday, October 8, 2024 1:45 AM
To: Leah Neukirchen <leah@vuxu.org>
Cc: Clem Cole <clemc@ccc.com>; Jacobson, Doug W [E CPE] <dougj@iastate.edu>; tuhs@tuhs.org; groff@gnu.org
Subject: Re: [TUHS] Re: Old troff files (1988-2007)

Hi Leah,

At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote:
> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
> > Anton Shepelev wrote a summary I find admirably concise and blunt:
> >
> > "`grotty' is not an appendix to a pager, but a program for printing 
> > direct to the terminal.  Most terminals support those basic ANSI 
> > control sequences, and many console programs freely use them.  If a 
> > pager cannot transparently forward them to the terminal, it is a 
> > problem of the pager, not of `grotty', and having a broken -man 
> > configuration by default to just to appease `less' is stupid."
> 
> I don't see the problem, less supports -R for the last 25 years...

Yeah.  People's ire seems to rise from the fact that grotty's default is to assume SGR support and less's default is to not interpret SGR.

I would prefer that `-R` were less's default; that would better serve the larger proportion of ECMA-48 video terminals using the pager versus those using it with (an emulator of) hardcopy terminals.

Whatever transition process needs to commence for that to happen, I think it should.

But in the meantime it's no great effort for me (nor for most people) to alias 'less' to 'less -R', write a shell function to do similarly, or just type three more characters.

(For those requiring accessibility assistance, shell aliases and functions, programmable key bindings, and similar should serve as they do the merely impatient.)

Regards,
Branden

[TUHS] Re: Old troff files (1988-2007)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

[dropped Clem and Leah from CC]

Hi Doug,

At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote:
> Using Groff (eqn+pic) + grap I was able to create a PDF of the book.
> It took about 8 hours

8-O

> part of which was figuring out the syntax differences.

Oh, wall clock time including human engagement.  That sounds really
reasonable!  I'm not sure I want to estimate how many hours I've put
into revising groff's own documentation.  Or ncurses's.

Eight hours processing time on a modern machine (without inflooping)
would be shocking to me.

> He had divided the book up into a file for each page or two, so 100+
> files.  I think he did that, so he did not waste paper since he had to
> print out the pages to see if they looked right, no display to view
> them.

No PostScript or PDF preview program?  I can think of a few: mupdf,
evince, okular.  Deri James (groff developer) can probably name a dozen.

> It was not perfect but is good enough for the publisher to review.
> The book is on filters (EE book) and is full of graphs, circuits, and
> equations.  He used pic to draw the circuits, which was amazing.  This
> was fun to take a forgotten manuscript written by a colleague and with
> luck maybe getting it published while he is still alive.  If the
> publisher wants to publish it, I'm not sure how they will handle troff
> files :)

If you'd care to share it with me in my capacity as groff maintainer,
I'd be interested to use it for unofficial regression testing.

Alternatively, if you can't find an interested publisher, please
consider asking the author (I assume he's also the copyright holder) to
release it under a Creative Commons license so the whole world can
enjoy.  Also, so I can selfishly enjoy the pleasure of pointing to a
sophisticated typeset work and saying, "look what groff can do!"  ;-)

(Just in case people aren't impressed enough with K&R or W. Richard
Stevens.)

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Old troff files (1988-2007)

[Jacobson, Doug W [E CPE] via TUHS]

Branden:

8 hours of my time, not computer time.  

The faculty member started this in 1988, and we (the department) did not have access to much in the way of visual previewing.  He was an EE by training, and really latched onto Unix, vi, troff, etc.  At the time we were running a series of AT&T 3B2/5, and a 3B20.  My wife was sysadmin and I was on the faculty.  We had a large number of faculty and staff using troff for editing and publishing.  I remember my wife teaching Unix and Troff to faculty.  We did have a few of the AT&T graphics terminal (I cannot remember the model number)  Another fun thing, I used troff and vi (on a different) system to write my Ph.D. in 1985.

I will reach out to you about the files etc.  He is the copyright holder.  His health is not good, and his family with the help of a former student is the one hoping to get it published.  

Doug
 

-----Original Message-----
From: G. Branden Robinson <g.branden.robinson@gmail.com> 
Sent: Tuesday, October 8, 2024 5:50 AM
To: Jacobson, Doug W [E CPE] <dougj@iastate.edu>
Cc: tuhs@tuhs.org; groff@gnu.org
Subject: Re: [TUHS] Re: Old troff files (1988-2007)

[dropped Clem and Leah from CC]

Hi Doug,

At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote:
> Using Groff (eqn+pic) + grap I was able to create a PDF of the book.
> It took about 8 hours

8-O

> part of which was figuring out the syntax differences.

Oh, wall clock time including human engagement.  That sounds really reasonable!  I'm not sure I want to estimate how many hours I've put into revising groff's own documentation.  Or ncurses's.

Eight hours processing time on a modern machine (without inflooping) would be shocking to me.

> He had divided the book up into a file for each page or two, so 100+ 
> files.  I think he did that, so he did not waste paper since he had to 
> print out the pages to see if they looked right, no display to view 
> them.

No PostScript or PDF preview program?  I can think of a few: mupdf, evince, okular.  Deri James (groff developer) can probably name a dozen.

> It was not perfect but is good enough for the publisher to review.
> The book is on filters (EE book) and is full of graphs, circuits, and 
> equations.  He used pic to draw the circuits, which was amazing.  This 
> was fun to take a forgotten manuscript written by a colleague and with 
> luck maybe getting it published while he is still alive.  If the 
> publisher wants to publish it, I'm not sure how they will handle troff 
> files :)

If you'd care to share it with me in my capacity as groff maintainer, I'd be interested to use it for unofficial regression testing.

Alternatively, if you can't find an interested publisher, please consider asking the author (I assume he's also the copyright holder) to release it under a Creative Commons license so the whole world can enjoy.  Also, so I can selfishly enjoy the pleasure of pointing to a sophisticated typeset work and saying, "look what groff can do!"  ;-)

(Just in case people aren't impressed enough with K&R or W. Richard
Stevens.)

Regards,
Branden

[TUHS] Re: Old troff files (1988-2007)

[Anton Shepelev]

Jacobson, Doug W:

> Long  story short, I have a unpublished manuscript that a fac-
> ulty member in my department wrote late 1980's  early  2000's.
> He  did  the entire thing in troff, eqn, and pic.  The faculty
> member is still alive.   A  publisher  is  interested  in  the
> manuscript.  I have all of the source files on an old unix ma-
> chine that still has troff, eqn and pic.  It also has groff.

*roff has so spectacular a backwards compatibiliy that its  mod-
ern  implementaions will not only accept a source from the 1970s
but actually produce a historically accurate  rendition  of  it.
Unlike  MS  Word,  *roff  the kind of software that you need not
bother to keep an old version to open your old files.

I therefore suggest that you install a modern *roff and seek as-
sistance with your task in its community.  GNU Troff is the only
one I know and use (even for this e-mail), can recommend it  for
both  hard (the program itself) and soft (the friendly community
and great maintaner) qualities.  They are  also  interested  and
successful  in  recreating  historial documents, so feel free to
ask in their mailing list.