At 2021-02-21T20:34:55-0600, Will Senn wrote: A more up to date copy is available at the Linux man-pages site. https://man7.org/linux/man-pages/man1/groff.1.html What strikes _me_ about the above is the awful Denglish in it. I fixed this back in 2017 and the correction shipped as part of groff 1.22.4 in December 2018. I'd say it's neither, and reflects (1) the limitations of the Unix filter model, or at least the linear topology of Unix pipelines[1]; and (2) an arbitrary set of rules determined by convention and common practice with respect to sequencing. Consider the first the question of which *roff preprocessor languages should be embeddable in another preprocessor's language. Should you be able to embed equations in tables? What about tables inside equations (not too insane an idea--consider matrix literals)? Nothing in the Unix filter model implies a choice between these decisions, but an ordering decision must be made. V7 Unix tbl(1)'s man page[3] took a moderately strong position on preprocessor ordering based on more practical concerns (I suppose loading on shared systems). When it is used with .I eqn or .I neqn the .I tbl command should be first, to minimize the volume of data passed through pipes. Another factor is ergonomics. As the number of preprocessors expands, the number of potential orderings of a document processing pipeline also grows--combinatorially. Here's the chunk of the groff front-end program that determines the ordering of the pipeline it constructs for the user. // grap, chem, and ideal must come before pic; // tbl must come before eqn const int PRECONV_INDEX = 0; const int SOELIM_INDEX = PRECONV_INDEX + 1; const int REFER_INDEX = SOELIM_INDEX + 1; const int GRAP_INDEX = REFER_INDEX + 1; const int CHEM_INDEX = GRAP_INDEX + 1; const int IDEAL_INDEX = CHEM_INDEX + 1; const int PIC_INDEX = IDEAL_INDEX + 1; const int TBL_INDEX = PIC_INDEX + 1; const int GRN_INDEX = TBL_INDEX + 1; const int EQN_INDEX = GRN_INDEX + 1; const int TROFF_INDEX = EQN_INDEX + 1; const int POST_INDEX = TROFF_INDEX + 1; const int SPOOL_INDEX = POST_INDEX + 1; Sure, you could have a piece of paper with the above ordering taped to the wall near your terminal, but why? Isn't it better to have a tool to keep track of these arbitrary complexities instead? groff, as a front-end and pipeline manager, is much smaller than the actual formatter. According to sloccount, it's 1,195 lines to troff's 23,023 (measurements taken on groff Git HEAD, where I spend much of my time). If you need to alter the pipeline or truncate it, to debug an input document or resequence the processing order, you can, and groff supplies the -V flag to help you do so. A traditionalist need never type the groff command if it offends one's sensibilities--it would be a welcome change from people grousing about copyleft. All the pieces of the pipeline are still there and can be directly invoked. For an alternative approach to *roff document interpretation and rendering, albeit in a limited domain, see the mandoc project[4]. It interprets the man(7) and mdoc(7) macro languages, a subset of *roff, and tbl(1)'s mini-language with, as I understand it, a single parser. Regards, Branden [1] Tom Duff noted this a long time ago in his paper presenting the rc shell[2]; see §9. [2] https://archive.org/details/rc-shell/page/n2/mode/1up [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/tbl.1 [4] https://mandoc.bsd.lv/

Will Senn writes: I'm 99% happy with groff and its many options. Why? Because the various programs (troff, pic, tbl, eqn, ...) are still available and can be composed into pipelines of my own choosing. The 1% unhappiness is because I think that groff should be a shell script which it doesn't appear to be. In my opinion, if groff was a bad thing then one would have to question things like scripts and aliases in general. Groff is a composer, and composability is a core UNIXism to me. It would be way wrong if it replaced all of the programs that it invoked, but it doesn't. As an interesting example of the composability of the troff system, I did the diagrams for my book using pic because pic is awesome. But, despite what it says in the No Starch Press author guidelines, they really only accept material in word format. I could have rendered each image as a bitmap, but that just seemed so 80s. Turns out that while it doesn't do a great job, word will accept vector graphics in SVG format. So I ran each image through pic, through groff, through ps2pdf (embedding fonts), through pdf2svg, and finally through inkscape to crop the image. A tad cumbersome, but it works, and wouldn't be easy to do on any other system. I also did my original draft in troff and wrote a script to convert it into openoffice XML format so that it could be word-ified. Only part that I couldn't figure out was how to include the figures; I could generate the XML but it didn't work and there were no useful diagnostics so I had to import them by hand. Since Rob is on the list and (in)famous for the "cat -v" argument, I would agree with him that that is not the "right" way. Being consistent with my position on groff, I would go for a separate show-nonprinting utility and then, if widely used, a script that composed that and cat. Jon