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.