> Sent: 12 September, 2026 7:26 AM > To: [email protected] > Cc: [email protected] > Subject: Re: improving "approximate" output (was: deprecating deroff & > unroff) > Ingo Schwarze wrote: > Page Breaks ----------- > Page breaks are clearly a typesetting feature, so they are among > the features that deserve to be unconditionally removed.
Hyphenation and Justification ----------------------------- > Automatic hyphenation is clearly a typesetting feature, > so -a ought to completely disable automatic hyphenation. > In addition to being clear from the definition of what -a > is supposed to be, typical applications like spell checking > make it even clearer that automatic hyphenation would be > counter-productive. Completely agree on both. Additionally, justification should be disabled, as it also is clearly a typsetting feature. In a text file, it’s usually extra garbage that a user needs to clean up. I almost always use ragged right anyway, so this usually isn’t an issue for me. I handled all of this with my front-end to Elan Eroff (this long predated groff). We used mm for everything but man pages, so we added register X, which, if set, would ensure that register Hy was 0, call “.SA 0”, and set register L to a very large number. It obviously would be nice to have a package-independent way to do this. I thank Ingo for not chastising me ;-) Character Encoding ------------------ > I suspect (without being sure) this lack of clarity may be due to > UTF-8 not having been a thing yet when -a was originally designed, > and hence "plain text" may have been silently assumed to imply > US-ASCII. The ‘a’ option was available 40 years ago, when UTF-8 clearly did not exist. I think “plain text” is a much better way of putting things. Though UTF-8 would seem a reasonable default nowadays, some users might prefer ASCII or some 8-bit encoding, e.g., cp1252 for Windows people who still use Windows Console host, or Latin1 for folks on other systems. > Escape sequences are omitted from the output. Of course. > > 5. develop a (discardable) notation for drawing commands > > By definition, plain text cannot represent non-trivial drawing, > so almost all drawing commands should simply be removed. Yep——we did this as well for the reasons stated. > One might argue about a very small number of trivial edge cases > that could arguably be represented in plain text, like horizontal > and vertical lines. But since the line will be hard to draw - > pun intended - what to represent and what to not represent, > it's probably better to consistently discard all drawing commands. Agree; too tricky to count on. > In terminal output, i.e. in nroff/grotty proper, it makes sense to > be inventive and represent the document as usefully as possible for > a terminal user, maybe even inventing ASCII art schemes for drawing > commands, if somebody wants to work on that. I’m less a fan of “ASCII art” than I was years ago, especially with non-ASCII characters. On a printed page——where one could backspace and overstrike——it was not always obvious what the result was intended to represent. And in text output, of course, this isn’t even possible. In some cases, such as em dashes, a double hyphen works fine; for me, an asterisk works fine for a bullet. In other cases, e.g. Greek or other characters, something like a TeX name might be better——at least the reader knows what’s intended. With UTF-8, of course, this shouldn’t be an issue. “Approximate Output”: a Different Objective? -------------------------------------------- The folks who really know can speak to this better than I, but it seems to me the ‘a’ option served a different purpose: an approximation of what would obtain before sending the output to a typesetting device. What we’ve been discussing is simply creating a plain text file. Logically, it’s not really “formatted” for anything, because the ultimate purpose may not be known. So perhaps the ‘a’ option should remain as is and a new option could handle creating a text file. Call it fancy deroffing, I guess. > "Generate plain text" seems clear enough to me, and conceptually > a signifantly more restrictive subset of terminal output. I agree. Plain text can go only so far. But in many cases, it’s enough. And with a few tweaks, groff could do a very good job of it. Unlike what obtains from all too many other programs even today. Jeff
