Re: Standardize roff

[Alexis]

Sam Varshavchik  writes:


I believe that for man pages, roff
should've been replaced by Docbook XML a long time ago.


Personally, i'm grateful that it hasn't. Apart from Ingo's 
thorough critique of DocBook:


   https://undeadly.org/cgi?action=article&sid=20190419101505

i doubt i'd have had as much enthusiasm for creating the man page 
ports of s6-related documentation if i'd had to use DocBook, 
rather than being able to use mdoc(7). In fact i probably wouldn't 
have done them at all.



Alexis.

Re: Standardize roff

[Sam Varshavchik]

Ingo Schwarze writes:


Hi San,

Sam Varshavchik wrote on Sun, Aug 14, 2022 at 08:20:34PM -0400:
> Ingo Schwarze writes:
>> DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:

>>> Have we ever considered a de jure *roff standard?

>> No, i think that would be pure madness given the amount of working
>> time available in any of the roff projects.

> I tinkered with something like this some years ago, but I took a slightly
> different approach.
>
> I converted man pages

What kind of manual pages?


The ones that are the subject of discussions on linux-...@vger.kernel.org.


> from 'roff source to Docbook XML using a … pretty large Perl script.

That sounds very foolish on several levels.


Well, I had some free time the other day, and had nothing better to do.


First, and most obviously, you seem to be duplicating esr@'s work
on doclifter:

  http://www.catb.org/~esr/doclifter/
  https://gitlab.com/esr/doclifter/-/blob/master/doclifter


Seems so, except that I tailored my logic to man pages, and specifically to  
the linux-...@vger.kernel.org manpages.



Second, quick and dirty Perl-style parsing is usually not good
enough to parse roff code, and a huge script is not particularly
good for readability and maintainability.


Yes, arbitrary roff code will not fly very far. But something that's  
tailored can produce productive results.



Yes, i know the same resevations would apply to esr@'s work,
which is a giant Python 3 script.  But at least there is some
evidence that his work was able to find significant numbers of
real issues in real manual pages.


Yes, there are plenty of issues there. I fed quite a few patches to Mr.  
Kerrisk when he maintained them, based on my scripts chewing through them.  
There were plenty of mismatched .nf/.fi, and other things of that sort.




> Once a year, or so, when I have nothing better to do I pull the current
> man  page tarball and reconvert it. I usually need to tinker the Perl
> script, here and there, each time.
>
> The Docbook folks provide a stylesheet that converts Docbook XML
> back to 'roff.

Yikes.  That thing is by far the worst man(7) code generator existing
on this planet.  If at all possible, you should avoid that toolchain
like the plague.


I do not view it as an authoritative source of man sources, but more of  
backwards compatibility. I believe that for man pages, roff should've been  
replaced by Docbook XML a long time ago.


That was really the original impetus for my Perl hacking: to see how  
feasible it would be to convert the existing man pages to Docbook XML. My  
end result showed that at least that it was doable; and I think that the  
Docbook XML stylesheet for man pages would've been an acceptable way to get  
some roff source generated from Docbook XML that's shown by the man command.



> The end result you get is standardized 'roff, whatever that means.

Absolutely not.  The result is utter crap.  It is rarely even
syntactically valid, let alone reasonable style.


I should've used "consistent" instead of "standardized". Different man pages  
from different sources use different ways of rendering the same content,  
i.e. function names. Sometimes it's in bold. Sometimes it's in italic.  
Sometimes it's something else. With consistent semantic markup a   
in every man page would've produced the same markup in the generated roff  
source.





pgpVD7G808LBH.pgp
Description: PGP signature

Re: Standardize roff

[Ingo Schwarze]

Hi San,

Sam Varshavchik wrote on Sun, Aug 14, 2022 at 08:20:34PM -0400:
> Ingo Schwarze writes:
>> DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:

>>> Have we ever considered a de jure *roff standard?

>> No, i think that would be pure madness given the amount of working
>> time available in any of the roff projects.

> I tinkered with something like this some years ago, but I took a slightly  
> different approach.
> 
> I converted man pages

What kind of manual pages?

> from 'roff source to Docbook XML using a … pretty large Perl script.

That sounds very foolish on several levels.

First, and most obviously, you seem to be duplicating esr@'s work
on doclifter:

  http://www.catb.org/~esr/doclifter/
  https://gitlab.com/esr/doclifter/-/blob/master/doclifter

Second, quick and dirty Perl-style parsing is usually not good
enough to parse roff code, and a huge script is not particularly
good for readability and maintainability.

Yes, i know the same resevations would apply to esr@'s work,
which is a giant Python 3 script.  But at least there is some
evidence that his work was able to find significant numbers of
real issues in real manual pages.

> Once a year, or so, when I have nothing better to do I pull the current
> man  page tarball and reconvert it. I usually need to tinker the Perl
> script, here and there, each time.
> 
> The Docbook folks provide a stylesheet that converts Docbook XML
> back to 'roff.

Yikes.  That thing is by far the worst man(7) code generator existing
on this planet.  If at all possible, you should avoid that toolchain
like the plague.

It is so bad that for years, bogus reports caused by that totally
broken toolchain have caused the majority of invalid mandoc bug
reports.

> The end result you get is standardized 'roff, whatever that means.

Absolutely not.  The result is utter crap.  It is rarely even
syntactically valid, let alone reasonable style.

> But, yes, the effort require to clean up and standardize the formatting
> of man pages would be mammoth. There's more inconsistency across the
> various man pages, from various sources, than consistency.

That isn't completely untrue, but all the same, mandoc copes well
enough with more than 95% of valid real-world manual pages, and groff
with 100%.  In a nutshell, the only stuff that breaks with groff
is manual pages that are completely invalid, usually coming from
the official DocBook XML toolchain, and in rarer cases coming from
other broken man(7) generators.

All this is barely related to the question of standardizing roff(7),
though.  Roff is much more than manual pages.

Yours,
  Ingo

Re: Standardize roff (was: *roff `\~` support)

[Ingo Schwarze]

Hi Alejandro,

Alejandro Colomar wrote on Mon, Aug 15, 2022 at 01:59:24PM +0200:
> On 8/14/22 21:43, DJ Chase wrote:

>> Do you think that a descriptive/trailing standard could be beneficial
>> or would you still say that it could mostly hinder *roff
>> implementations?

When prepared with diligence and without falling for featurism,
it might be useful because the common subset of the major roff
implementations is large enough that it would likely be possibly
prepare portable roff documents following such a standard.

However, such a standard could likely *not* include *any* of the
best features of any of the implementations: yes, implementations
have diverged that much - not quite as bad as make(1), but still more
than many other classical Unix programs.  Consequently, only authors
with modest needs could possibly consider adhering to the standard.
To provide some striking examples, the standard could include neither
the mom(7) macro set - which is a killer feature of groff - nor the
mdoc(7) macro set - which has been an important feature of groff for
more than 30 years and of mandoc for more than 10 years.

This is all theoretical though - as i explained, the effort required
for developing such a (necessarily seriously stunted) standard is
prohibitive.

[...]
> But we can achieve something very similar by documenting the differences 
> between known roff alternatives somewhere.  And that's likely to be much 
> easier.

That's a much lower bar than a standard, but don't underestimate
the effort involved even in that.

A few very small parts of that already exist.

For example,

  https://mandoc.bsd.lv/man/man.options.1.html

documents command line options of some roff(1) and man(1)
implementations, mostly intended for people who see themselves
forced to invent a new command line option - which should of course
be avoided if at all possible because the tangle of existing options
is already terrifying.

For example,

  https://man.openbsd.org/roff.7

documents roff requests and roff escape sequences; search for
"extension" in that page.  Even though this page focusses on groff,
Heirloom, and mandoc and does not mention Plan 9, neatroff, or other
implementations, the amount of compatibility information scattered
around that page is already larger than what would seem healthy for
most user-facing documentation.  It's OK here because this page is
geared more towards developers than towards users.
Also, note that this page is already very long even though it is
extremely terse - so terse that it is insufficient for learning
how to use most of the features mentioned.

> In the Linux man-pages we document when a function is in ISO C or in 
> POSIX, but also when it's not standardized but present in other Unix 
> systems (so that it has some degree of portability), or when it is 
> Linux-only.  Maybe having something similar in groff's manual pages 
> would be effective.

Except that the bulk, and in particular the core, of groff functionality
is *not* described in manual pages in the first place.  Would you
want to litter groff.texi with compatibility information throughout?
That would likely cause a significant increase in size, almost certainly
a very signifant decrease in maintainability, and possibly it might also
somewhat decrease readability.

> For example, for .MR, we were discussing that probably it would be good 
> to add a note like "(since groff 1.23.0)" and maybe it could also state 
> which other roff (or mandoc) implementations support it.

But that feels like an exception rather than the rule.  It seems
warranted for this particular case because we are introducing a
new feature without consideration for compatibility that will cause
information loss for end-users unless something unusual is done
about it.  Hopefully, we are not going to turn that vice into a habit.

The particular case of .MR is somewhat specific to manual pages, too.
If people prepare a typeset document using many advanced features with
groff or Heirloom, they are used to the fact that it won't work with
the other, nor with Plan 9.  That's not a major problem because most of
the time, the author is the only person who really needs to typeset a
document.  Nowadays, the average reader will only read the PDF version,
which is totally different from the situation with manual pages.

Yours,
  Ingo

Re: Standardize roff (was: *roff `\~` support)

[Alejandro Colomar]

Hi,

On 8/14/22 21:43, DJ Chase wrote:

True; prescriptive standards can certainly make some things worse. As a
further example, ISO 8601 sucks. I mean, its core specification is
great, but there are so many different ways that are allowed that the
full standard is almost completely unparseable. It also uses a slash
between the start and end times of a period instead of something
sensible, like, I don’t know, an en-dash! Which means that periods can
be written with a slash (because that’s the standard) but also with an
en-dash (because that’s how ranges work in English), but also that one
can’t properly write a period in a file name or URI.

Still, though, I think descriptive standards can be net-positive. The
POSIX shell utilities comes to mind. Sure, they certainly have some
issues, but because it’s a trailing standard, implementers are free to
fix them.

Do you think that a descriptive/trailing standard could be beneficial
or would you still say that it could mostly hinder *roff
implementations?


Well, a standard that truly recognizes the authority of implementations 
to drive the language and doesn't do anything else but describe the best 
already-implemented ways to achive things is a good thing.  It can't 
hinder future implementations, because it doesn't have the power to 
drive the future of the language, only describes the past.


POSIX C has been doing good in that; much better than ISO C.

I don't understand how POSIX works internally, though.  If some entity 
can fund (and is interested in) such a standardization process, it could 
bring some good.  But yeah, it will likely be very costly in time and 
money.  Worth it?  I don't know.


But we can achieve something very similar by documenting the differences 
between known roff alternatives somewhere.  And that's likely to be much 
easier.


In the Linux man-pages we document when a function is in ISO C or in 
POSIX, but also when it's not standardized but present in other Unix 
systems (so that it has some degree of portability), or when it is 
Linux-only.  Maybe having something similar in groff's manual pages 
would be effective.


For example, for .MR, we were discussing that probably it would be good 
to add a note like "(since groff 1.23.0)" and maybe it could also state 
which other roff (or mandoc) implementations support it.


Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Re: Standardize roff (was: *roff `\~` support)

[Sam Varshavchik]

Ingo Schwarze writes:


Hi,

DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:

> Have we ever considered a de jure *roff standard?

No, i think that would be pure madness given the amount of working
time available in any of the roff projects.

I expect the amount of effort required to be significantly larger
than the amount of effort that would be required for rewriting
the entire groff documentation from scratch because:


I tinkered with something like this some years ago, but I took a slightly  
different approach.


I converted man pages from 'roff source to Docbook XML using a … pretty  
large Perl script.


Once a year, or so, when I have nothing better to do I pull the current man  
page tarball and reconvert it. I usually need to tinker the Perl script,  
here and there, each time.


The Docbook folks provide a stylesheet that converts Docbook XML back to  
'roff. The end result you get is standardized 'roff, whatever that means.


But, yes, the effort require to clean up and standardize the formatting
of man pages would be mammoth. There's more inconsistency across the
various man pages, from various sources, than consistency.



pgphXqg1SoVB0.pgp
Description: PGP signature

Re: Standardize roff (was: *roff `\~` support)

[DJ Chase]

On Sun Aug 14, 2022 at 6:35 PM EDT, G. Branden Robinson wrote:
> At 2022-08-14T14:49:10+, DJ Chase wrote:
> > On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> > > DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:
> > >
> > > > Have we ever considered a de jure *roff standard?
> > >
> > > No, i think that would be pure madness given the amount of working
> > > time available in any of the roff projects.
>
> Mark your calendars--Ingo and I are in substantial agreement.  ;-)
>
> > This is very sad to hear.
>
> I think the take-away here is that the decision to formally standardize
> a technology, like many things, is an economic one.  There are costs and
> benefits.  Being seduced by the benefits without a full understanding of
> the costs often leads to remorse.  (And, in many domains, fat
> commissions for sales personnel.)
>
> > That’s probably because *I* massively overrate the importance of
> > standardization (I mean I literally carry a standards binder with me).
> > Still, though, it’s rather annoying that end users — especially
> > programmers — don’t value standards as much.
>
> I think it is less that programmers value standards in the wrong amount,
> than that they disregard them for the wrong reasons--like "moving fast"
> and building fragile solutions that will cost more on the back end after
> higher-paid decision makers have moved on to greener pastures.
>
> Nothing succeeds like handing your successor a trash fire.
>
> > Would an informal de jure standard
>
> You just defined "de facto standard".  ;-)
>
> "De jure" is Latin for "of the law".  If something is not codified in
> "law", or a normative document like a formal standard, then what is
> "standard" is simply the intersection of prevailing practices.

By “informal de jure”, I meant ‘de jure, but written in an informal
manner’.

> > be of any use? Like how TOML just has a specification, but it’s
> > somewhat usable as a standard because it’s been pretty stable and
> > because it’s written clearly enough.
>
> A purely descriptive document, mainly comprising a matrix of features
> with escape sequence, request, and predefined register names on one axis
> and the names of implementations on the other, with version numbers and
> commentary populating the elements, could be a useful thing to have.

I’m on it (except not really, because we’re in the middle of a move,
school resumes shortly, and etc. But eventually™, I’m on it).

Cheers,
-- 
DJ Chase
They, Them, Theirs

Re: Standardize roff (was: *roff `\~` support)

[G. Branden Robinson]

At 2022-08-14T14:49:10+, DJ Chase wrote:
> On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> > DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:
> >
> > > Have we ever considered a de jure *roff standard?
> >
> > No, i think that would be pure madness given the amount of working
> > time available in any of the roff projects.

Mark your calendars--Ingo and I are in substantial agreement.  ;-)

> This is very sad to hear.

I think the take-away here is that the decision to formally standardize
a technology, like many things, is an economic one.  There are costs and
benefits.  Being seduced by the benefits without a full understanding of
the costs often leads to remorse.  (And, in many domains, fat
commissions for sales personnel.)

> That’s probably because *I* massively overrate the importance of
> standardization (I mean I literally carry a standards binder with me).
> Still, though, it’s rather annoying that end users — especially
> programmers — don’t value standards as much.

I think it is less that programmers value standards in the wrong amount,
than that they disregard them for the wrong reasons--like "moving fast"
and building fragile solutions that will cost more on the back end after
higher-paid decision makers have moved on to greener pastures.

Nothing succeeds like handing your successor a trash fire.

> Would an informal de jure standard

You just defined "de facto standard".  ;-)

"De jure" is Latin for "of the law".  If something is not codified in
"law", or a normative document like a formal standard, then what is
"standard" is simply the intersection of prevailing practices.

> be of any use? Like how TOML just has a specification, but it’s
> somewhat usable as a standard because it’s been pretty stable and
> because it’s written clearly enough.

A purely descriptive document, mainly comprising a matrix of features
with escape sequence, request, and predefined register names on one axis
and the names of implementations on the other, with version numbers and
commentary populating the elements, could be a useful thing to have.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Standardize roff (was: *roff `\~` support)

[DJ Chase]

On Sun Aug 14, 2022 at 12:32 PM EDT, Alejandro Colomar wrote:
> On 8/14/22 16:49, DJ Chase wrote:
> > On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> >> You appear to massively overrate the importance end-users
> >> typically attribute to standardization.
> > 
> > That’s probably because *I* massively overrate the importance of
> > standardization (I mean I literally carry a standards binder with me).
> > Still, though, it’s rather annoying that end users — especially
> > programmers — don’t value standards as much.
>
> (Official) standardization isn't necessarily a good thing.  With C, it 
> was originally good, in the times of ISO C89.  Now, it's doing more 
> damage to the language and current implementations than any good (it's 
> still doing some good, but a lot of bad).
>
> [Snipped because I’m not going to quote the whole email — see previous
> message for argument]
>
> I think it's better to let natural selection to work out its way.  If a 
> feature is good, other implementations will pick it, and maybe even 
> improve it.  If a feature is not good (or it's not needed by other 
> systems), it will not be portable.

True; prescriptive standards can certainly make some things worse. As a
further example, ISO 8601 sucks. I mean, its core specification is
great, but there are so many different ways that are allowed that the
full standard is almost completely unparseable. It also uses a slash
between the start and end times of a period instead of something
sensible, like, I don’t know, an en-dash! Which means that periods can
be written with a slash (because that’s the standard) but also with an
en-dash (because that’s how ranges work in English), but also that one
can’t properly write a period in a file name or URI.

Still, though, I think descriptive standards can be net-positive. The
POSIX shell utilities comes to mind. Sure, they certainly have some
issues, but because it’s a trailing standard, implementers are free to
fix them.

Do you think that a descriptive/trailing standard could be beneficial
or would you still say that it could mostly hinder *roff
implementations?

Cheers,
-- 
DJ Chase
They, Them, Theirs

Re: Standardize roff (was: *roff `\~` support)

[Alejandro Colomar]

Hi,

On 8/14/22 16:49, DJ Chase wrote:

On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:

Hi,

DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:


Have we ever considered a de jure *roff standard?


No, i think that would be pure madness given the amount of working
time available in any of the roff projects.

[…]


This is very sad to hear.


It could also lead to more users & use cases because existing
users could count on systems supporting certain features, so
they could use *roff in more situations, which would lead to
more exposure.


You appear to massively overrate the importance end-users
typically attribute to standardization.


That’s probably because *I* massively overrate the importance of
standardization (I mean I literally carry a standards binder with me).
Still, though, it’s rather annoying that end users — especially
programmers — don’t value standards as much.


(Official) standardization isn't necessarily a good thing.  With C, it 
was originally good, in the times of ISO C89.  Now, it's doing more 
damage to the language and current implementations than any good (it's 
still doing some good, but a lot of bad).


The best that a standardization process can do is limit itself to 
describe _only_ features already existing in the language, being a kind 
of arbiter that decides on which behavior is best for a given feature, 
so that all implementations follow the best existing one.  Where 
different implementations might have good reasons to do it differently, 
the standard should describe the behavior as implementation-specific. 
And of course, a standard should only standardize features that are 
expected to be good for every implementation, with optional features 
either not being standardized, or being marked optional by the standard 
(like Annex K was; although that one was broken, so it was later removed 
for good).


But that shouldn't be necessary if implementors had some decency and 
didn't implement features so that they are completely incompatible with 
those of other systems.  I.e., if an existing system has 'foo(int a);', 
you don't provide 'foo(int *b);'; you go for 'foo2(int *b);' or 'bar(int 
*b);'.  There's plenty of cases where this has happened, and in some 
cases it might be due to an accident, but in some other cases, it's just 
due to incompetence.  See an example that bit me a month ago: 
.


And the bad things that standardization can do are several:

By reserving the power to centrally decide the future of a language, 
they take power from implementations, which now can't add some features, 
by fear that they might contradict a future standard.  This is very sad, 
because while the implementations are guided by usefulness and 
worthiness, and try to come up with the best feature for them (and by 
natural selection, implementations are then used or not used, depending 
on their quality), standards have a large part of bureaucracy, and that 
doesn't provide the best features.


A few examples of that are: a %b printf specifier for binary was 
rejected by glibc on the terms of something like "the feature is good, 
and the implementation seems correct, but %b is reserved by the 
standard, so we don't want to possibly conflict with a future standard"; 
luckily, the standard defined that, and the feature was added a few 
years later.  One example that is much more necessary is a way to get 
the size of an array, which currently is impossible in portable C (at 
least not in a way that safely rejects to compile on non-arrays).  I 
also proposed an addition to glibc, and the reasons to reject it were of 
the same kind, and arguing that the standard was discussing about adding 
such a feature; guess what? the standard hasn't added such a feature for 
C23, and we still have no portable way to do it (and the unportable ways 
are more cumbersome than what one would expect).  I hope C3x adds 
_Lengthof(arr), but who knows.






And then we have another problem of standardization committees: their 
priorities are so broken, that they prefer inventing a completely new 
feature for C, with nothing even remotely resemblant to it within the 
existing language (I'm talking about nullptr and nullptr_t), rather than 
standardizing an existing good feature such as POSIX's NULL  ((void *) 
0).  So now we have 0, NULL, and nullptr for referring to a null pointer 
constant in C.  And none of them is perfect.  0 needs to be casted when 
passed to variadic functions, and has readability issues.  NULL is 
perfect within the POSIX world, but if you go out of POSIX, it's as bad 
as 0.  nullptr, apart from being incomprehensible, it is unsafe; okay 
it's not unsafe by itself, and if it were the only way to refer to a 
null pointer constant, it would be great, but it's not, and 

Re: Standardize roff (was: *roff `\~` support)

[DJ Chase]

On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> Hi,
>
> DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:
>
> > Have we ever considered a de jure *roff standard?
>
> No, i think that would be pure madness given the amount of working
> time available in any of the roff projects.
>
> […]

This is very sad to hear.

> > It could also lead to more users & use cases because existing
> > users could count on systems supporting certain features, so
> > they could use *roff in more situations, which would lead to
> > more exposure.
>
> You appear to massively overrate the importance end-users
> typically attribute to standardization.

That’s probably because *I* massively overrate the importance of
standardization (I mean I literally carry a standards binder with me).
Still, though, it’s rather annoying that end users — especially
programmers — don’t value standards as much.

> > It’s ridiculous that *roff isn’t part of POSIX when it was Unix’s
> > killer feature.
>
> You are welcome to spend the many years required to change that.
> But be aware that some standardization efforts that are part of
> POSIX resulted in parts of the standard that are barely useable
> for practical work.  One famous example is make(1).
>
> Don't get me wrong: i think standardization is very nice to have,
> should be taken very seriously when available, and provides some
> value even when the standardization effort mostly failed, like in
> the case of make(1).  But standardization is absolutely not cheap.
> To the contrary, it is usually significantly more expensive than
> implementation and documentation.

Would an informal de jure standard be of any use? Like how TOML just has
a specification, but it’s somewhat usable as a standard because it’s
been pretty stable and because it’s written clearly enough.

Cheers,
-- 
DJ Chase
They, Them, Theirs

Standardize roff (was: *roff `\~` support)

[Ingo Schwarze]

Hi,

DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +:

> Have we ever considered a de jure *roff standard?

No, i think that would be pure madness given the amount of working
time available in any of the roff projects.

I expect the amount of effort required to be significantly larger
than the amount of effort that would be required for rewriting
the entire groff documentation from scratch because:

 1. You would have to study all features of all the major roff
implementations (groff, Heirloom, neatroff, Plan 9, and possibly
some others, maybe even historical ones) and compare the features.
For every difference (i.e. typically multiple times for almost every
feature), you would have to descide which behaviour to standardize
and what to leave unspecified.

 2. Discussions of the kind mentioned in item 1 are typically
lengthy and often heated.  If you don't believe me, just buy
several pounds of popcorn and watch the Austin list, where
maintenance of the POSIX standard is being discussed.
Even discussions of the most minute details tend to be
complicated and extended.

 3. Even after deciding what you want to specify, looking at the
manuals typically provides very little help because a
standard document requires a completely different style.
User and even reference documentation is optimized for clarity,
comprehensibility, and usefulness in practice; a standard document
needs to be optimized for formal precision, whereas
comprehensibility and conciseness matters much less.

 4. Even when you have the text - almost certainly after many years
of work by many people - be prepared for huge amounts of red
tape, like dealing with elected decision-making bodies of
professional associations, for example the IEEE.  Be prepared
for having to know things like what technical societies,
technical councils, and technical committees are, and how to
deal with each of them.  You are certainly in for a lot of
committee work, and i would count you lucky if you got away
without having to deal with lawyers, paying membership fees,
buying expensive standard documents you need for your work,
and so on and so forth.  Even when you submit a technically
perfect proposal, it will typically be rejected without even
being considered until you secure the official sponsorship
of at least one of the following: the IEEE, the Open Group,
or ISO/IEC JTC 1/SC 22.  Of course, your milage may vary
depending on what exactly you want to standardize and how,
but since roff(1) is arguably the most famous UNIX program,
i wouldn't be surprised if you were if for an uanbridged
POSIX-style Odyssey.

 5. The above is not helped by standards committee work being
typically conducted in ways that are technically ridiculously
outdated, and i'm saying that as an avid user of cvs(1) who
somewhat dislikes git(1) as overengineered and very strongly
detests GitHub.  Take the Austin groups as an example.  Most of
its work is changing the content of technical documents,
but the group *never* uses diff(1), never uses patch(1), and
never makes diffs available even after they have been approved.
They are very firmly stuck in the 1980ies regarding the technolgies
they are using and missed even most of the 1990ies innovations.
They do have some kind of version control system internally, but
no web interface of such version control ins publicly available,
nor any other public read-only access to that version control.
Even the source code of the finished version of the standard
is typically not made available to the public (at least not
without forcing people to jump through hoops).

> A standard could lead to more implementations because
> developers would not have to be intimately familiar with the
> {groff,heirloom,neatroff} toolchain before implementing a
> *roff toolchain themselves.

That's not even wishful thinking.  Better maintenance of the
existing implementations would be so much more useful than yet
another implementation.

> It could also lead to more users & use cases because existing
> users could count on systems supporting certain features, so
> they could use *roff in more situations, which would lead to
> more exposure.

You appear to massively overrate the importance end-users
typically attribute to standardization.  Even people *implementing*
a system rarely put such an emphasis on standardization.

> It’s ridiculous that *roff isn’t part of POSIX when it was Unix’s
> killer feature.

You are welcome to spend the many years required to change that.
But be aware that some standardization efforts that are part of
POSIX resulted in parts of the standard that are barely useable
for practical work.  One famous example is make(1).

Don't get me wrong: i think standardization is very nice to have,
should be taken very seriously when available, and provides s