Hi Ingo, At 2026-09-12T16:26:09+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Sat, Sep 12, 2026 at 12:36:43AM -0500: > > Here's the configuration space as I currently model it. > > I think you are seriously overthinking and overengineering this. > The following list feels eclectic, arbitrary, and of no relevance > to the task. > > I mean, the whole point of -a (and tools like deroff) is to refrain > from both typesetting and markup and just reduce the input to plain > text.
No, it was originally designed as a previewer, so you could judge, among other things, where the line breaks were going to be. That helps when preparing documents for an audience, like a journal editor, that can veto your work by insisting on window/orphan elimination, a limit on consecutive hyphenated lines, or a limit on page count. In the U.S., courts impose limits on the lengths of briefings from the parties all the time. I get that you want to kill hyphenation with a thousand stakes to the heart, but it remains important in typesetting--foremost because it is one of many factors determining the page layout. The purpose of "groff -a", like "troff -a", is _not_ to prefigure mandoc(1), but to give you a foretaste of the layout of the output. An advantage for developers is that we can, to some extent, perform end-to-end tests of output drivers for hardware we don't have. That's a live problem in groff now, and has been for years, with the grolbp(1) driver. Because its device and font description files still need to be loaded and used, that and a syntactical sanity check on the generated grout (which I hope someday to generalize gxditview(1) to support) can give us some confidence in our support for the device, or at least isolate problems to the driver executable itself, which is an important step in troubleshooting. $ groff -a -T lbp ~/Documents/lorem_ipsum.groff | head <beginning of page> Sed ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem ape<hy> riam eaque ipsa, quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo. Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ra<hy> tione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet consectetur adipiscivelit, sed quia non-numquam eius modi tempora incidunt, ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipitlaboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit, qui inea voluptate velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla pariatur? At vero eos et ac<hy> cusamus et iusto odio dignissimos ducimus, qui blanditiis praesentium voluptatum deleniti atque corrupti, quos do<hy> One can do a differential analysis of that with "-T ps" and "-T lj4", for example. > If you want any typesetting or markup, just use an output device that > supports what you want. I invite Dave Kemper to field your detailed points, as he pays more attention to the `-a` feature than anyone else I know. > The design of an output device should start from are clear purpose > and scope. `-a` isn't an output device. While we can now render to actual devices/file formats at a speed that would have dizzied the denizens Bell Labs CRSC in its heyday, I can see a reason for `-a`'s purpose to be permitted to adapt such that it offers insight into the formatter's state or decisions without the terrifyingly comprehensive detail of recursive node traversal I implemented for 1.24.0, and which reaches full fire hose pressure with the "secret" environment variable `GROFF_DUMP_NODES`. Now then, if no one _asks for_ some kind of previewing or instrumentation level between the fire hose and rendering to an output device, and I don't find I need it myself (as an aggressively exploring user), then _that_ is a good reason not to implement the enhancements I pitched. > Such a design should not arbitrarily add random afterthoughts, lest it > turn into a confusing and unmaintainable mess. "Generate plain text" > seems clear enough to me, The people who came up with Markdown had similar thoughts. That's why there's only ever been one successful dialect of it... `:-| > and conceptually a signifantly more restrictive subset of terminal > output. Even terminal output supports none of the random, ad-hoc > markup options you envision for -a. And we support dumbed-down terminal output, too with "grotty -cbou". Soon, perhaps, to be enhanced with a `-C` option and perhaps `TERM=dumb" of synonymous meaning. groff is not mandoc. Keep the projects' distinct missions in mind. Regards, Branden
signature.asc
Description: PGP signature
