9 Jul
2022
9 Jul
'22
4:58 a.m.
All, Matt e-mailed this to me and the TUHS list, but it doesn't seem to
have made it through so I'm punting on a copy ...
Warren
----- Forwarded message from Matt Gilmore -----
Subject: Documents for UNIX Collections
Good afternoon everyone, my name is Matt Gilmore, and I recently worked with some folks
here to help facilitate the scanning and release of the "Documents for UNIX"
package as well as a few odds and ends pertinent to UNIX/TS 4.0. I've been
researching pretty heavily the history of published memoranda and how they ultimately
became the formal documents that Western Electric first published with UNIX/TS 5.0 and
System V. Think the User's Guide, Graphics Guide, etc.
In my research, I've found that document sets in a similar spirit have been published
since at least Research Version 6. I've been able to track down a few that are on
the TUHS source archive in original *ROFF format (Links given as path in the tree to avoid
hyperlink mangling):
Research V6: V6/usr/doc
Mini-UNIX: Mini-Unix/usr/doc
PWB/UNIX 1.0: PWB1/usr/man/man0/documents
(note, I'm not sure where the actual docs are, this is just a TOC, Operators
Manual is in op in the base man folder)
Wollongong 7/32 Version: Interdata732/usr/doc (only 7/32 relevant docs, allegedly)
Research V7: V7/usr/doc
UNIX/32V: 32V/usr/doc
There are probably others, but these are the ones I'm aware of on the archive for
Bell-aligned revisions prior to the commercialization of UNIX/TS as System III. On the
note of System III, I seem to have an archive that is slightly different than what is on
TUHS, namely in that it has this same documents collection. I can't find it in the
System III section on the site, so I'm assuming it isn't hosted anywhere
presently. One of the projects I'm working on (slowly) is comparing these documents
with the 4.0 docs I scanned for Arnold and making edits to the *ROFF sources with the
hopes I could then use them to produce 1:1 clean copies of the 4.0 docs, while providing
an easy means for diff'ing the documents as well (to flush out changes between 3.0
and 4.0). Happy to provide this dump to Warren for comparison with what is currently
hosted.
Usenix also published documentation sets for 4.2 and 4.3BSD in the 80's which served
the same purpose for BSD users. There seems to be a 4.4BSD set as well, although I
haven't looked at these yet, I've got a random smattering between 4.2 and 4.3 of
the comb-bound Usenix manuals, but I assume the 4.4 set is in a similar vein, with
reference guides and supplementary documents. Looks like a lot of the same, but with
added documents regarding developments at Berkeley.
Now for my reasons for mailing, there are a couple:
1. Is anyone aware of whether similar document sets were compiled for MERT, UNIX/RT, USG
Program Generic, or CB-UNIX? Or would users of those systems have simply been referred to
the collection most closely matching the version they're forked from?
2. Was there ever any such document set published in this nature as "Documents for
UNIX" consistent of memoranda for 5.0/System V? Or did USG immediately begin by
providing just the published trade manuals? The implication here is if USG published no
such documents, then the Documents for UNIX 4.0 represents the last time USG compiled the
memoranda as they were written (of course with version-related edits) with original
authorship and references as a documentation set.
3. Have there been any known efforts to analyze the history and authorship of these
documents, explicitly denote errata and revisions, and map out the evolution of the system
from a documentation perspective like this?
Thanks for any insight anyone can provide!
- Matt G.
P.S. I'd be interested in doing more preservation work, if anyone else has documents
that need preserving, I'll happily coordinate shipment and scanning.
P.P.S. Ccing Warren, I don't know if I'm able to send emails to this list or
not, so pardon the extraneous email if not necessary.
----- End forwarded message -----
9 Jul
9 Jul
6:40 a.m.
New subject: Retypesetting Unix documents (was: Documents for UNIX Collections)
[not CCing Matt because his address didn't come through to the list]
Hi Matt,
At 2022-07-09T08:58:10+1000, Warren Toomey via TUHS wrote:
----- Forwarded message from Matt Gilmore -----
Subject: Documents for UNIX Collections
Good afternoon everyone, my name is Matt Gilmore, and I recently
worked with some folks here to help facilitate the scanning and
release of the "Documents for UNIX" package as well as a few odds and
ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily
the history of published memoranda and how they ultimately became the
formal documents that Western Electric first published with UNIX/TS
5.0 and System V. Think the User's Guide, Graphics Guide, etc.
That's excellent work--thank you for doing it!
One of the projects I'm working on (slowly) is
comparing these
documents with the 4.0 docs I scanned for Arnold and making edits to
the *ROFF sources with the hopes I could then use them to produce 1:1
clean copies of the 4.0 docs, while providing an easy means for
diff'ing the documents as well (to flush out changes between 3.0 and
4.0).
Are you using groff to do your rendering? If so, please consider me a
resource; I've been the most active groff developer for the past 4
years. (I am, however, not the release manager--we're feeling heavily
pregnant with groff 1.23, 3.5 years in the making.)
Some of the following issues may be familiar to you; I apologize if I
wear a rut in well-trodden ground here.
I am wondering what you mean by "1:1 clean copies". I embarked on a
similar exercise only about a week ago with the Kernighan & Cherry
document "Typesetting Mathematics -- User's Guide (Second Edition)",
which was part of Volume 2 of the V7 Unix Programmer's Manual.
In the course of that effort I learned several things. I identified
(and fixed) bugs in groff's ms(7) implementation, and to my surprise
also discovered one in, apparently, V7 troff that caused an equation at
the bottom of a column to go missing. Because groff was independently
developed, the equation sprung back to life in its rendering. You can
find a narrative of my experiences at the following thread, along with
commentary from others.
https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html
Pixel-perfect matching of C/A/T (or APS-5, etc.) output will be
impossible because the fonts are different. More than that, the font
_metrics_ are different, which means lines will not always fill the same
when comparing historical typesetter output and a modern
implementation's (this will be true even if you use Heirloom Doctools
Troff, which is descended from V7 Unix, but has seen many changes over
the years, starting with Kernighan's revision for device-independence
ca. 1980, plus many changes for the commercial Documenter's Workbench
product, and then many more by Gunnar Ritter and his successors in the
Heirloom project).
Beyond that, Unix troff and groff use different hyphenation systems. I
don't know how stable Unix troff's was over time.
All of that said, with the Kernighan and Cherry document, by spending
just a few minutes eyeballing old scans and groff PostScript output,
flicking between two fullscreen viewers like an ersatz blink comparator,
and using binary search to tweak the ms(7) LL, PO, and MINGW registers,
I was able to _almost_ perfectly match column and page breaks between
the two renderings, which was a higher fidelity of reproduction than I
expected. The risen equation noted above was the most dramatic change.
Encouraged by that experience, I also reset the V7 Unix version of the
article "A System for Typesetting Mathematics". This apparently was
_not_ published in the Programmer's Manual, possibly because much of its
content was duplicated in the user's guide. But the amount of effort
required of me was shockingly low. On the other hand, for this I didn't
have an authentically typeset copy to compare to, so all I did was look
for what I would consider rendering errors as opposed to cosmetic
changes. (Maybe this the standard you want to apply in your own work?)
I'm attaching a diff.
Another apparent difference arises between V7 Unix eqn and groff eqn; in
eqn input such as "lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1", V7
eqn will recognize "->" as beginning a new token and convert it to a
right arrow glyph in the output, despite the manual (as I understand it)
implying that it won't. groff eqn _does_ require token separation in
this case.
I say that differences are "apparent", rather than making the stronger
claim of outright bugs in V7 Unix tools mainly because I don't have a
cat2dit(1) tool I can run in my V7 Unix environment in SIMH. In my
opinion such a tool (in K&R C, of course) would be well worth having.
Right now, to satisfy myself of V7 Unix troff behavior I have to produce
an octal dump of the typesetter output, pull it out of the emulation
environment with copy-and-paste, undump it with a custom program (xxd is
not helpful), and then give the reconstructed C/A/T stream to an
interpreter written by John Garder in JavaScript. John's tool (and his
personal assistance) has proven invaluable, but it's a component of a
larger project of his that renders device-independent troff output in a
Web browser window. For this to be practical he has to introduce
additional device-independent troff commands into the output. I'd
prefer something more rabidly puritan (and, if I'm honest, something
written in a more traditional Unix system programming language).
https://github.com/Alhadis/Roff.js/
The big advantage of a V7 Unix/PDP-11 cat2dit(1) would be that
device-independent troff output is plain text and much easier to spirit
out of the emulated environment to the host system. Also, some people,
who may be pitied, have taught themselves to read it, making more
observations possible and hypotheses testable within the PDP-11
environment. (In principle, this is also true of C/A/T command streams,
whether raw or octal-encoded, but I'll just let the pity roll downhill.)
Thanks largely to Henry Spencer, the information to write a new
cat2dit(1) from scratch is available. Eventually, if no one else does
so, I will undertake it myself; but my queue is deep (mostly with groff
defect reports and feature requests).
https://github.com/Alhadis/otroff/blob/92683053f9aad5b926fc447843bf2092ad59…
Dan Plassche pointed me toward Adobe Transcript, but my understanding is
that it falls short of my needs in 3 ways: it produces PostScript, which
I can't easily read, not device-independent troff output (which I can);
it's not available in a version ready to run in a modern Unix
environment; and it has a licensing encumbrance. I'd like a cat2dit(1)
we can all trade around libre and gratis.
Alternatively, if someone leaked the troff sources from UNIX/TS 4.0,
that would bring a grin of Jack Nicholsonian proportions to my face.
That should be buildable in vivo on a PDP-11 and would facilitate much
other historical research besides. (With it, someone could annotate a
diff of the troff/nroff source trees between V7 and UNIX/TS 4.0, which I
wager constitutes a highly positive and teachable moment in software
design and engineering.)
Okay, brain dump terminated. Please let me know if I can help.
Regards,
Branden
9:57 p.m.
New subject: Retypesetting Unix documents (was: Documents for UNIX Collections)
Thanks for all of the background Branden. I would be using Groff so this is all very
valuable information, I'm glad someone with expertise is watching!
I have already noticed the differences in width, but haven't looked to far into it
yet. The effort would likely involve two phases: one to apply changes to the 3.0 docs to
match the content of 4.0, then once the content is updated, the remaining matter is
formatting consistency (as much as possible) with the typeset documents we have scans of.
If it ain't perfect, that's alright. The implication would be that the original
3.0 documents on the Autologic system would be formatted similarly, so the edits would
produce *ROFF input that, back then, would spit these documents out. Perhaps identical
typesetting would be a bit ambitious, but failing that, content modification
shouldn't be as difficult. Plus, processing the 3.0 docs today with Groff would
produce documents with the same alignment, so for comparison purposes it'd all still
be very useful.
Thanks again for the reply, I'll have to reach out when I'm more regularly
working on this again, work and summer have been my primary time sinks lately :)
- Matt G.
------- Original Message -------
On Friday, July 8th, 2022 at 5:40 PM, G. Branden Robinson
<g.branden.robinson(a)gmail.com> wrote:
[not CCing Matt because his address didn't come
through to the list]
Hi Matt,
At 2022-07-09T08:58:10+1000, Warren Toomey via TUHS wrote:
----- Forwarded message from Matt Gilmore -----
Subject: Documents for UNIX Collections
Good afternoon everyone, my name is Matt Gilmore, and I recently
worked with some folks here to help facilitate the scanning and
release of the "Documents for UNIX" package as well as a few odds and
ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily
the history of published memoranda and how they ultimately became the
formal documents that Western Electric first published with UNIX/TS
5.0 and System V. Think the User's Guide, Graphics Guide, etc.
That's excellent work--thank you for doing it!
One of the projects I'm working on (slowly)
is comparing these
documents with the 4.0 docs I scanned for Arnold and making edits to
the *ROFF sources with the hopes I could then use them to produce 1:1
clean copies of the 4.0 docs, while providing an easy means for
diff'ing the documents as well (to flush out changes between 3.0 and
4.0).
Are you using groff to do your rendering? If so, please consider me a
resource; I've been the most active groff developer for the past 4
years. (I am, however, not the release manager--we're feeling heavily
pregnant with groff 1.23, 3.5 years in the making.)
Some of the following issues may be familiar to you; I apologize if I
wear a rut in well-trodden ground here.
I am wondering what you mean by "1:1 clean copies". I embarked on a
similar exercise only about a week ago with the Kernighan & Cherry
document "Typesetting Mathematics -- User's Guide (Second Edition)",
which was part of Volume 2 of the V7 Unix Programmer's Manual.
In the course of that effort I learned several things. I identified
(and fixed) bugs in groff's ms(7) implementation, and to my surprise
also discovered one in, apparently, V7 troff that caused an equation at
the bottom of a column to go missing. Because groff was independently
developed, the equation sprung back to life in its rendering. You can
find a narrative of my experiences at the following thread, along with
commentary from others.
https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html
Pixel-perfect matching of C/A/T (or APS-5, etc.) output will be
impossible because the fonts are different. More than that, the font
metrics are different, which means lines will not always fill the same
when comparing historical typesetter output and a modern
implementation's (this will be true even if you use Heirloom Doctools
Troff, which is descended from V7 Unix, but has seen many changes over
the years, starting with Kernighan's revision for device-independence
ca. 1980, plus many changes for the commercial Documenter's Workbench
product, and then many more by Gunnar Ritter and his successors in the
Heirloom project).
Beyond that, Unix troff and groff use different hyphenation systems. I
don't know how stable Unix troff's was over time.
All of that said, with the Kernighan and Cherry document, by spending
just a few minutes eyeballing old scans and groff PostScript output,
flicking between two fullscreen viewers like an ersatz blink comparator,
and using binary search to tweak the ms(7) LL, PO, and MINGW registers,
I was able to almost perfectly match column and page breaks between
the two renderings, which was a higher fidelity of reproduction than I
expected. The risen equation noted above was the most dramatic change.
Encouraged by that experience, I also reset the V7 Unix version of the
article "A System for Typesetting Mathematics". This apparently was
not published in the Programmer's Manual, possibly because much of its
content was duplicated in the user's guide. But the amount of effort
required of me was shockingly low. On the other hand, for this I didn't
have an authentically typeset copy to compare to, so all I did was look
for what I would consider rendering errors as opposed to cosmetic
changes. (Maybe this the standard you want to apply in your own work?)
I'm attaching a diff.
Another apparent difference arises between V7 Unix eqn and groff eqn; in
eqn input such as "lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1", V7
eqn will recognize "->" as beginning a new token and convert it to a
right arrow glyph in the output, despite the manual (as I understand it)
implying that it won't. groff eqn does require token separation in
this case.
I say that differences are "apparent", rather than making the stronger
claim of outright bugs in V7 Unix tools mainly because I don't have a
cat2dit(1) tool I can run in my V7 Unix environment in SIMH. In my
opinion such a tool (in K&R C, of course) would be well worth having.
Right now, to satisfy myself of V7 Unix troff behavior I have to produce
an octal dump of the typesetter output, pull it out of the emulation
environment with copy-and-paste, undump it with a custom program (xxd is
not helpful), and then give the reconstructed C/A/T stream to an
interpreter written by John Garder in JavaScript. John's tool (and his
personal assistance) has proven invaluable, but it's a component of a
larger project of his that renders device-independent troff output in a
Web browser window. For this to be practical he has to introduce
additional device-independent troff commands into the output. I'd
prefer something more rabidly puritan (and, if I'm honest, something
written in a more traditional Unix system programming language).
https://github.com/Alhadis/Roff.js/
The big advantage of a V7 Unix/PDP-11 cat2dit(1) would be that
device-independent troff output is plain text and much easier to spirit
out of the emulated environment to the host system. Also, some people,
who may be pitied, have taught themselves to read it, making more
observations possible and hypotheses testable within the PDP-11
environment. (In principle, this is also true of C/A/T command streams,
whether raw or octal-encoded, but I'll just let the pity roll downhill.)
Thanks largely to Henry Spencer, the information to write a new
cat2dit(1) from scratch is available. Eventually, if no one else does
so, I will undertake it myself; but my queue is deep (mostly with groff
defect reports and feature requests).
https://github.com/Alhadis/otroff/blob/92683053f9aad5b926fc447843bf2092ad59…
Dan Plassche pointed me toward Adobe Transcript, but my understanding is
that it falls short of my needs in 3 ways: it produces PostScript, which
I can't easily read, not device-independent troff output (which I can);
it's not available in a version ready to run in a modern Unix
environment; and it has a licensing encumbrance. I'd like a cat2dit(1)
we can all trade around libre and gratis.
Alternatively, if someone leaked the troff sources from UNIX/TS 4.0,
that would bring a grin of Jack Nicholsonian proportions to my face.
That should be buildable in vivo on a PDP-11 and would facilitate much
other historical research besides. (With it, someone could annotate a
diff of the troff/nroff source trees between V7 and UNIX/TS 4.0, which I
wager constitutes a highly positive and teachable moment in software
design and engineering.)
Okay, brain dump terminated. Please let me know if I can help.
Regards,
Branden
680
days inactive
681
days old
2 comments
3 participants
participants (3)
-
G. Branden Robinson -
segaloco -
Warren Toomey