On Sun, Sep 22, 2024 at 6:52 PM G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > [discussion moved to groff@ which is a discussion list; I feel that > bug-groff@, like groff-commit@, is not--Reply-To set accordingly]
Agreed, but the message to which you're replying wasn't "discussion" on bug-groff@, but a comment posted at http://savannah.gnu.org/bugs/?62814 and thence reflected to bug-groff@. Nonetheless, replying here since discussion has now migrated here. > A person who has composed a table entry or any portion of a document > where filling has off, and employed a special character like \(mo or > \(*e or \(ca, is likely working from an expectation that whatever gets > typeset at that place in the text is not going to be wider than, say, > one em. A fair point. But the alternative, on a terminal where tty-char.tmac is NOT used, is a "special character not defined" warning and these characters missing from the output altogether. (None of them are defined in tty.tmac.) But yes, omitting those characters from the output does keep them from being wider than 1 em... > 2. a user's preference of whether the "visual" vs. "semantic" fallback > character definitions are used. But that's not the choice the user is presented with. As the original submission of #62814 notes, "both files contain (disjoint) sets of tty fallback character definitions." So the choices are "semantic" fallbacks vs. missing characters. The sets being disjoint was true when I wrote that in 2022. It's not strictly true as of last month's commit c9b3c99a6 (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c9b3c99a6), which moved a number of alphabetic characters with diacritical marks from fallbacks.tmac to tty.tmac, giving tty.tmac. and tty-char.tmac slightly different fallback definitions for these characters. But even this overlap has little bearing on the points above: both versions of each of these fallbacks is a net 1 en wide; both versions are defined with the \z escape to overstrike two characters, just with slightly different characters in each case. (If anything, these common elements between the two files should be removed, and one set of overstruck characters be considered the canonical terminal fallback. As pointed out elsewhere, whatever terminal you're using is unlikely to support overstriking anyway.)
