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.  If you want any typesetting or markup, just use an output
device that supports what you want.


> 1.  report page breaks

Page breaks are clearly a typesetting feature, so they are among
the features that deserve to be unconditionally removed.


> 2.  distinguish "automatic" hyphens from explicit ones

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.


> 3.  promote explicit hyphens to notation for `hy` special character

Over-engineering.  In plain text output, explicit hyphens should
simply be plain-text hyphens and nothing else, or the output
will be some ad-hoc made-up markup language and not plain text.


> 4.  develop a (discardable) notation for indexed characters[2]

Nowadays, the concept of "plain text" could mean either US-ASCII
or UTF-8 text.  The groff(1) manual page fails to say which one of
the two it is aiming for.
>From experimentation with 1.25.0rc2, it appears it does neither,
but instead invents its own (undocumented?) <charname> markup.

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.

However this contradiction will be resolved, inventing even more
pseudo-markup doesn't look like a reasonable direction.

The (mostly unmaintained) demandoc(1) utility at least documents
what it does, which more or less implies that it produces US-ASCII
output, though it could admittedly be more explicit:

   Escape sequences are omitted from the output.


> 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.

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.

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.

But when the goal is explicitly "plain text", i would call
such inventiveness misguided.  Otherwise, what would be the
conceptual difference between -a and terminal output?


> 6.  develop a (discardable) notation for device extension commands

The sounds like an egregious contradiction in itself.  The whole
point of -a is printing for a plain text device, which by its very
definition supports no device extensions, so all device extension
attempts have to result in no output.


> At present, I think of all of these as toggles.

I think none of these have any place in plain text output.


> But that's still 2^6 = 64 possible configurations.

I want a toggle to somehow mark words that bear stress emphasis,
and another toggle to somehow distinguised words that were built
up from some kind of roff(7) programming or macros as opposed to
words contained in the source docuemnt, and another toggle to
distinguish words taken from text lines from words input as
macro arguments, and another toggle to distinguish English
words from French words.

This is not sustainable.  Once you start going down rabbit holes
of "i want plain text, but not really," what people want to have
marked up becomes an entirely arbitrary, infinite stream of
haphazard personal whims.

The design of an output device should start from are clear purpose
and scope.  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, 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.

Yours,
  Ingo

Reply via email to