On Sunday, 26 July 2026 22:40:39 British Summer Time G. Branden Robinson wrote: > Hi Larry, > > At 2026-07-26T00:50:49-0400, Larry Kollar wrote: > > > G. Branden Robinson <[email protected]> wrote: > > > I'd like to avoid doing what TeX does (or what its usual front-end > > > does), and do what appears to be multi-pass formatting even when > > > it's not necessary. Or maybe it _doesn't_ apply multiple passes > > > unnecessarily, but its ordinary operation is so garrulous that I > > > struggle to tell the difference. > > > > In the years around 2004-2010, I maintained a pretty large[1] firmware > > guide in Groff. Standard procedure was a two-pass format: build the > > table of contents during the first pass, along with all forward > > references, then the second pass resolved all the page numbers. > > Rarely, maybe once or twice a year, I needed a third pass when > > pagination interfered with cross-references. But even on a blue Mac G3 > > (1999 model), typing “make” and walking to the bathroom gave me a > > clean PDF before I returned. > > > > I’m not saying there are no use cases where 2026-vintage hardware > > needs help building groff, but I believe it’s true that (besides > > Deri’s eye-popping use case) the vast majority of groff users aren’t > > going to notice an extra pass when it comes to processor usage. > > Deri's pretty good at finding mad-scientist applications for groff. > It's great! :D
Possibly one of my maddest is my perl script which converts several binary embroidery machine formats (such as PES and DST) into roff (so I can create a pdf which shows the stitching the machine will do). Example is Squirrel.pdf. > [...] > > > [1] “Pretty large” = around 1000 pages across four docs. Later on, I > > consolidated it into a single manual that ran 700-900 pages depending > > on build-time options. > > On my system using my working copy, which is about 28 commits ahead of > our master branch in Savannah, groff produces our 408-page collected man > pages document in about 7 seconds. > > $ rm ./build/doc/groff-man-pages.pdf > $ time make -C build > make: Entering directory '/home/branden/src/GIT/groff/build' > make all-recursive > make[1]: Entering directory '/home/branden/src/GIT/groff/build' > make[2]: Entering directory '/home/branden/src/GIT/groff/build' > GROFF doc/groff-man-pages.pdf > troff: backtrace: file '<standard input>':1075 > troff:<standard input>:1075: warning: special character '.j' not defined [-w > char] troff: backtrace: file '<standard input>':1481 > troff:<standard input>:1481: warning: special character 'vA' not defined [-w > char] troff: backtrace: file '<standard input>':1611 > troff:<standard input>:1611: warning: special character 'bs' not defined [-w > char] troff: backtrace: file '<standard input>':1784 > troff:<standard input>:1784: warning: special character '-+' not defined [-w > char] troff: backtrace: file '<standard input>':1833 > troff:<standard input>:1833: warning: special character 'coproduct' not > defined [-w char] troff: backtrace: file '<standard input>':1933 > troff:<standard input>:1933: warning: special character '+e' not defined [-w > char] make[2]: Leaving directory '/home/branden/src/GIT/groff/build' > make[1]: Leaving directory '/home/branden/src/GIT/groff/build' > make: Leaving directory '/home/branden/src/GIT/groff/build' > > real 0m7.148s > user 0m9.101s > sys 0m0.140s A bit quicker here:- real 0m3.471s user 0m4.416s sys 0m0.118s And we do know a way to speed that up, don't we Branden. :-) [...] > > * I observe that the mandoc(1)-generated PDF is 11 MB; ours is 1.6 MB. > Bad old bloated GNU stuff once again, eh?[D] It is written in PDF 1.1 (we use 1.7), no fonts are embedded (only TimesRoman family is used), there is no kerning or ligatures, all text is 11pt, and each separate word needs 5 separate pdf commands. Cheers Deri > I terminated my survey (except to peek ahead at eqn(1)) at page 223 of > 675. I think I've seen enough to produce an informed opinion. > > I've attached the respective PDF documents. The different _ordering_ of > the man page documents within is not mandoc(1)'s fault but merely an > artifact of my laziness in employing a shell variable as shown above. > > I don't expect any of these observations to impact BSD/mdoc/mandoc(1) > partisans' assessment of its superiority to groff in any way. It: > > * goes fast; > * isn't copylefted; > * isn't in C++. > > That, it seems, is all they require of it. > > Whether mandoc(1) faithfully manifests the principle of the Unix > philosophy holding that a tool should "do one thing and do it well", I > leave open to consideration. > > Regards, > Branden > > [A] https://cvsweb.bsd.lv/mandoc/?sortby=date#dirlist > [B] Good news, though! https://savannah.gnu.org/bugs/?68309 > [C] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.24.1#n547 > [D] > https://www.undeadly.org/cgi?action=article&sid=20100604082319&mode=expande > d
Squirrel.pdf
Description: Adobe PDF document
