Hi Dave, At 2025-09-10T05:43:16-0500, Dave Kemper wrote: > > + GNU troff offers the `char` request, enabling a document to > > + define `\[ru]` as equivalent to `_` if it wishes. > > Since this is a new requirement for documents that want this mapping, > whereas it used to happen by default, wouldn't this warrant a NEWS > item?
It could.
The rest of the commit log might be helpful:
* src/libs/libgroff/glyphuni.cpp: Stop mapping the special character
`ru` (baseline rule) to U+005F. The Unicode "LOW LINE" is a not a
baseline rule (while my DEC VT525's character set disagrees, the
fonts on my GNU/Linux box do not). `ru` and `bs` (the Bell System
logo) are the only special characters groff internally defines
that have no Unicode representation. ...
What do people here think?
> It's a minor change, but it *is* a change in the behavior of over 20
> years.
Noting the foregoing, it's arguably a bug fix.
NEWS:
This file describes recent user-visible changes in groff. Bug fixes
are not described. There are more details in the man and info
pages.
Bug fixes do tend to be observable to users, or they wouldn't be
reported in the first place.[1] In the instant case, it's possible that
we've had users who have been frustrated with the slight misplacement of
their (attempts at) baseline rules.
> What threshold is generally used for this?
Gut feeling, I think. I know that's a feeble answer.
Regards,
Branden
[1] That's not why I noticed the mapping. I noticed it because
`asciify`ing a diversion with a `\[ru]` in it didn't produce the
howling diagnostic about an un-asciifiable node that I expected.
Background: https://lists.gnu.org/archive/html/groff/2024-08/msg00085.html
signature.asc
Description: PGP signature
