[TUHS] Original print of V7 manual? / My own version of troff

[G. Branden Robinson]

At 2024-01-07T16:20:35-0800, Mychaela Falconia wrote:
> > It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the
> > troff, tbl, eqn, pic, refer and macros as supplied by Sun at that
> > time, and NOT any GNU ones. Why? These were the versions written by
> > AT&T that Sun got directly from them during their SVR4
> > collaboration. I used the PostScript output option to troff (which
> > obviously did not exist in 1979).
> 
> You did the right thing: the version you used certainly feels much
> more "right" than anything from GNU.

This sort of broad, nonspecific, reflexive derogation of groff (or GNU
generally) is unproductive and frequently indicative of ignorance.

Admittedly, groff does not attempt pixel-perfect reproduction of classic
Unix documentation, particularly not C/A/T output.

There's a good reason for that, and one that will challenge your efforts
as well, if you draw your scope as far back as the C/A/T.  (If your
horizon is 4.3BSD documents rendered as PostScript, you may be in luck.)
The problem is fonts.

The C/A/T's fonts did not even exist in the digital domain.  They were
produced from photographic plates.  Their reproduction is consequently
something of a pickle.

The good news is that the Adobe PostScript Times faces and their URW
clone are "pretty close" equivalents.  Close enough that I was able to
reproduce Kernighan & Cherry's "Typesetting Mathematics User's Guide --
Second Edition" (a.k.a. "the eqn manual") with fairly high fidelity.

https://github.com/g-branden-robinson/retypesetting-mathematics

This work required (1) some bug fixes to the GNU ms macros, now applied;
and (2) fine-tuning of the line length and page offset to compensate for
the different metrics of Adobe/URW Times versus the C/A/T's.

There is a third problem, whose resolution is in progress, when
producing PDF output from this document; slanted Greek symbols are
present but "not quite right".  This is because unlike PostScript, PDF
font repertoires generally don't provide a "slanted symbol" face.
gropdf author Deri James has committed some work to groff's Git
repository synthesizing such a face.  We expect it in groff 1.24.

But if you are going for pixel-perfect reproduction of documents that
used fonts you don't have, you're going to need to recreate the fonts
somehow--perfectly (at least for the glyphs that a given document uses).
One of the reasons Knuth was able to be so meticulously perfectionistic
with TeX and avoid regressions at the pixel placement level is because
he developed his own fonts along with just about everything else.  AT&T
troff did not make that choice.

Like AT&T troff, groff attempts to be a practical typesetting system.
One way I measure its success is by the fact that practiced AT&T troff
users like Brian Kernighan[1] and Doug McIlroy[2] use it for the
composition of new works, and speak of it with approval.  (Doug reports
bugs, some of which we manage to address.)

groff is not, primarily, a vehicle for nostalgia trips.

> After almost 20 y of intermittent development (started in the fall of
> 2004), I just made the first official release of my version of troff:
>
> https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.Z
> https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.gz

But there is room in the world for such things, particularly if they are
Free Software.  I was unable to determine that qjtroff is, except for a
few portions retaining UC Regents' copyright notices from the 1980s,[3]
and if these contain further original work by you (or others), then the
lack of a clear copyright notice and licensing information renders the
project "all rights reserved", meaning among other things that people
cannot redistribute to others, let alone make modifications--say, to add
the documentation that is not present.

README:
> Documentation: in 2012 I started writing a proper manual, but ran out
> of time (had to switch to other projects).  Because it can easily be
> another year or two or ... before I can get back to that documentation
> and finish it, I decided to release this software as-is, without docs.
> Too many projects, too little time...

In any event, the groff mailing list is the de facto water cooler for
all *roff developers, and I invite you to join it to stay abreast of
developments.  Discussion of non-groff *roffs is rare but welcomed.
Since there is no standard for *roff, it is the most useful forum for
discussion of, for instance, unspecified details of formatter or macro
package behavior.

(Unfortunately, sometimes people ask for help with Heirloom Doctools
troff and receive solutions that are applicable only to groff;
Heirloom's own community seems sadly too shy, or perhaps too attenuated,
to share its expertise.)

Regards,
Branden

[1] https://technicallywewrite.com/2023/06/01/groff
[2] https://lists.gnu.org/archive/html/groff/2023-07/msg00062.html

[3] There were also Adobe copyright notices in AFM files, which are not
    necessarily a problem since font _metrics_ are not copyrightable[4]
    and of course several false positives arising from the existence of
    "copyright" as a named glyph in fonts.

[4] At least not in the United States, and perhaps not in many countries
    of the world that are signatories to the various trade treaties
    (URAA-GATT, TRIPS, and so forth) through which WIPO has exported
    U.S. copyright law to a nearly global scope.  IANAL.  TINLA.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240107/c4a410f2/attachment.sig>