Follow-up Comment #6, bug #68133 (group groff): At 2026-04-25T18:09:33-0400, Dave wrote: > Follow-up Comment #5, bug #68133 (group groff): > > What is the drawback to allowing translations that have historically > worked in groff, especially those of which have worked even before > groff,
Have you seen bug #68132?
That's an example of a translation that "historically worked"--except in
groff for the last 37 years.
How long did it take someone to notice?
> to continue to work? Or, I guess more accurately, what is gained by
> banning them?
Semantic clarity, consistency, and corresponding reductions in the
number of corner cases that have to be documented, tested, and
maintained...while we trade most of the latter advantages away again for
things we support only in compatibility mode, such features are at least
firewalled off. Behind a feature gate, their oddball status is easier
for everyone to understand.
> I get that under the hood, \(+- is a character and \~ is not,
Not just under the hood. Our Texinfo manual is at pains to distinguish
characters from glyphs (or, in terminology I'm migrating away from
"symbols") and has been since long before I started contributing.
In our documentation I've been at pains to avoid discussion of formatter
internals (like "node") except when I feel forced to.
Why do you suppose that a user of a typesetting system is likely to be
able to achieve a high level of skill in that system without a clear
idea of what its definition of a "character" is?
Why should a typesetting system play fast and loose with that concept,
applying the term "character" consistently in several contexts, but
adding an ad hoc bucket of extensions to it in the case of one request
whose mnemonic is "character translation"?
Should the same extensions be interpreted by the GNU _troff_ requests
`trin` and `trnt`? Why or why not? Justify your answers.
> but why should this distinction matter to users just trying to
> accomplish something?
Whether the distinction matters to a user depends on _what_ it is
they're trying to accomplish. Textual substitution? The language has
strings for that.
> (Bug #65829 shows one possible use case.)
If I get this stuff hammered out the way I envision, that use case will
be served as follows.
.char \[stretchy-space] \~
.tr ~\[stretchy-space]
_groff_(7):
.char c [["]contents]
Define an ordinary, special, or indexed character c as
contents. Omitting contents gives c an empty definition.
...
A character defined by char can be used just like a glyph
provided by the output device. In particular, other
characters can be translated to it with the tr request; it
can be made the tab or leader fill character with the tc
and lc requests; sequences of it can be drawn with the \l
and \L escape sequences; and, if the hcode request is used
on c, it is subject to automatic hyphenation.
However, a user‐defined character c does not participate at
its boundaries in kerning adjustments or italic
corrections.
Why is the foregoing insufficient, especially for something that has
never worked before?
This ticket is not a covert operation to declare bug #65829 unfixable.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68133>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
