Re: [bug #62814] [PATCH] consolidate or distinguish tty.tmac and tty-char.tmac

[Dave Kemper]

On Sun, Sep 22, 2024 at 6:52 PM G. Branden Robinson
<g.branden.robinson@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.)