Hi Robert, At 2025-06-06T09:49:16+1000, Robert Thorsby wrote: > At the risk of poking my bib in again, I would suggest that there is a > plethora of lists of colour names.
I don't mind your speaking up at all; the sharing of relevant expertise
is seldom an intrusion.
> Why should groff be restricted to a small subset when it currently has
> the power to describe any colour?
No reason I can think of. Who has proposed restricting it?
> As a starting point, try looking at ImageMagick.
ImageMagick/GraphicsMagick is a big software system of itself. What
should I be looking at?
> Might I respectfully remind the members of this list that groff has a
> purpose well beyond merely creating man pages. Man pages are an
> extremely small part, albeit an important part, of groff.
Completely agreed.
> By all means hold the hands of the authors of man pages, as they seem
> surely to need hand holding,
Part of that is due to some software developers' approach toward
documentation, which, like automated testing, is to write it to the
minimal standard their manager will accept, and is then then fled from
at maximum speed.
Another part arises from a trend, long evident but not clearly codified
until the groff 1.22.4 release, of man pages using only a subset of
*roff formatter features, or least being written with the expectation
that some renderers do not implement the full troff feature set.
No one's proposed adding machinery to prevent man(7) documents from
invoking `defcolor`, `gcolor`, or `fcolor` requests, though I wouldn't
expect mandoc(1) to ever add support for them. I don't have a citation
handy, but I seem to remember that Ingo has expressed a dim view of
color variation in man pages.
> but please do not cripple groff to do so.
Who has proposed diminishing groff's feature set in any way?[1] Where
is this proposal so that I can evaluate it?
Regards,
Branden
[1] To be fair, I have. In the "NEWS" file for the forthcoming 1.24
release there are a few items that one might regard as "diminishing
groff's feature set". For all of these, workarounds,
alternative syntax, or alternative naming conventions exist.
I observe that I didn't note such workarounds or motivate the reason
in every case. Let me annotate this list with [[comments]].
NEWS:
* Support for terminal devices using the CCSID 1047 (EBCDIC) encoding
has been withdrawn.
[[This change partially clears the way for GNU troff interpreting
UTF-8 input directly (without preconv(1) preprocessor usage) in the
future. One can still use iconv(1) to covert a code page 1047
document to US-ASCII or ISO Latin-1 prior to its input to GNU troff.]]
* The `mso` request no longer attempts to open a macro file named, say,
"tmac.s" if "s.tmac" was specified as the argument and not found, nor
vice versa. This feature was a convenience for some old AT&T troff
installations, but few of those remain in the field, and of those
that we know to survive, neither (DWB 3.3 and Solaris 10) uses a
macro file naming convention for which this feature is any help.
`mso` now simply processes the macro search path for a file name
matching the request argument, and succeeds or fails depending on an
exact match.
If you desire this functionality for portability (keeping in mind
that `mso` is itself a groff extension), consider the following.
.\" Load the ms package, whatever it might be named.
.msoquiet s.tmac\" If file present, defines `LP` macro.
.if !d LP .msoquiet tmac.s
* GNU troff no longer accepts nonpositive page lengths. Attempting to
set one with the `pl` request clamps the page length to the vertical
motion quantum as `ll` does with the horizontal motion quantum in
AT&T and GNU troffs.
[[The former behavior appears to have been an unintended quirk, and
was not documented until groff 1.23.0. See
<https://savannah.gnu.org/bugs/?61453> for background.]]
* GNU troff no longer accepts a newline as a delimiter for the
parameterized escape sequences `\A`, `\b`, `\o`, `\w`, `\X`, and
`\Z`.
[[This syntax was documented but baffling, and inconsistent with
other delimited escape sequences. Many other delimiters are
available; choose one.]]
* The device-specific macro files loaded by "troffrc" automatically on
startup, such as "html.tmac", no longer perform font translations for
some font names used by varieties of AT&T troff ('C', 'Hb', 'HX', and
several others).
These names are not portable: in AT&T troff, the font repertoire,
like the special character repertoire, was device-dependent. Since
groff 1.23.0, GNU troff diagnoses attempts to use nonexistent font
names. We recommend addressing such portability issues wherever
suits you: (1) in a document, perhaps by using `ie` and `el` requests
and the `.g` register to test whether the formatter claims support
for groff extensions, then `ie` and `el` again with the `F` groff
conditional expression operator to check for font availability, and
to perform font remappings with the groff `ftr` request as desired;
(2) doing so in your "troffrc" file; or (3) by modifying these macro
files similarly. Users of the "dvi" and "lbp" output devices should
be aware that these devices don't supply full families of monospaced
fonts (and never have). See grodvi(1) and grolbp(1) for lists of
font names supported by each device.
The legacy names are retained for the "pdf" and "ps" devices for this
release; however, use of them prompts one warning in the "font"
category from the formatter per deprecated name. We expect to
withdraw support for the names completely in the next groff release.
See gropdf(1) and grops(1) for lists of font names supported by each
device.
* grog(1) no longer supports the `--ligatures` and `--run` options.
Simulate the former (which was specific to the "pdf" output device)
with the option sequence "-P -U -P y", and the latter by using the
command substitution feature of your shell; see section "Examples" of
groff(1).
[[These features, like groffer(1) from the same author, seemed
superfluous to me.]]
signature.asc
Description: PGP signature
