Dave Kemper and I believe that the right-hand sides of groff character definitions with the `char` request and its siblings (`fchar`, `fschar`, `schar`) should no longer be subject to `tr` character translation.
See https://savannah.gnu.org/bugs/?55155 for background. 1. It seems unlikely that anyone relies on doing this. 2. Heirloom troff, nominally compatible with groff extensions, ends up in a confused state if you try it there. 3. neatroff faithfully reproduces groff behavior here, so it would be good to get Ali Gholami Rudi's opinion of this change. 4. mandoc(1) appears to ignore `char` requests. 5. Doing this would enable a clearer separation of responsibilities between `tr` and `char`; namely, it would enable character translations with `tr` to become part of the formatter's environment, which is motivated by <https://savannah.gnu.org/bugs/?62691>. The idea here is that `tr`'s purpose is to permute the groff character set, the union of the set of ordinary characters (U+0021..U+007E) and a user-extensible set of special characters, whereas the purpose of the `char` family is to manipulate the members of the set of special characters. (You can try `.rchar a`, but it silently fails.) Thoughts? Regards, Branden
signature.asc
Description: PGP signature
