Re: Why are tty-char.tmac and tty.tmac separate files?

[G. Branden Robinson]

At 2022-07-10T16:55:41-0500, Dave Kemper wrote:
> Why are tmac/tty-char.tmac and tmac/tty.tmac separate files?  They
> both seem to serve essentially the same purpose: providing fallback
> character sequences for characters that may not exist in the terminal
> environment's encoding (especially the limited sets available to ASCII
> and Latin-1).

I can't speak to this comprehensively since I'm still the new guy, but I
can distinguish them in a few ways.

First of all, there is always a macro file named for the output driver
that gets run via troffrc.  (In fact, that's what most of the lines in
the shipping troffrc are concerned with.  There's some indirection
involved to support rendering with gxditview.)

So there's a ps.tmac, pdf.tmac, html.tmac, and so on.

tty.tmac does a few things that _aren't_ character/glyph
definition-related.  It sets the page offset to zero, which makes sense
for video terminals and their emulators.  It defines some color names,
which other output device macro files also do

Finally, it conditionally loads some macro files particular to the
output character encoding.  Those in turn deal with the translation of
input character code points.  (I find these facts to be in some tension,
and it may be part of what Werner flagged years ago as an undesirable
coupling between character encodings and output devices.)

> But they are called from different places: grotty's man page specifies
> that troffrc loads tty.tmac automatically for any terminal device;
> thus, these two commands, using a character defined in tty.tmac, both
> produce the same output:
> 
> $ echo '\[lh]' | nroff | cat -s
> $ echo '\[lh]' | groff -Tascii | cat -s
> 
> But, as its man page says, the nroff script specifies tty-char.tmac,
> which means that whether this file is loaded depends on which command
> is used.  This example uses a character defined in tty-char.tmac:
> 
> $ echo '\[dg]' | nroff | cat -s
> <*>
> 
> $ echo '\[dg]' | groff -Tascii | cat -s
> troff: <standard input>:1: warning: can't find special character 'dg'
> 
> $
> 
> There may be a valid reason for this separation, but I'm not sure what
> it is.  What are the use cases where a user wants one set of
> definitions but not the other?
> 
> A comment in tty-char.tmac (reiterated on the nroff man page) gives
> some small hint: "the optical appearance of the definitions contained
> in this file is inferior... to those of the replacement characters
> defined in the file tty.tmac."  But this must be a statement in
> general terms, as only one character is defined in both files:
> 
> $ egrep -h '^\.(f|tty-)char ' tmac/tty*.tmac | cut -f2 -d\ > /tmp/sym
> $ diff <(sort /tmp/sym) <(sort -u /tmp/sym)
> 232d231
> < \[sd]
> $ rm /tmp/sym
> $ fgrep '\[sd]' tmac/tty*
> tmac/tty-char.tmac:.tty-char \[sd] ''
> tmac/tty.tmac:.fchar \[sd] \[dq]
> 
> (And in this case, which fallback definition of the arc-second sign is
> "superior" is a judgment call, but whichever one it is ought to be
> used across the board.  Both are pure ASCII; \[dq] is ASCII 34, the
> straight double-quote character.)

I think that definition in tty-char.tmac should be dropped.  I added
fallbacks in tty.char for \[fm] and \[sd] (both CSTR #54 glyphs) in May
2021.  I seem to remember that Ingo followed suit at least for the
latter in mdoc.

> So the upshot isn't that using only tty.tmac gives "better" results;
> the upshot is that using only tty.tmac leaves some character escapes
> undefined for terminals, provoking warnings and omitting information
> from the output.
> 
> And in a couple of cases, tty.tmac (the file that's always loaded)
> seems to presume the loading of tty-char.tmac (the file that's NOT
> always loaded): tty.tmac defines two glyphs in terms of \[rn], but
> \[rn] is defined for terminal devices in tty-char.tmac.

What I was trying to do was shut up warnings from the groff_char(7) man
page.

We simply can't be sure (without testing "\*[.T]") in tty.tmac that
we're going to have an output device that can do anything approximating
an extension for a radical sign.  Its most useful application requires
overstriking capability, which we don't actually expect any of our
terminal output devices to have.

Nevertheless rendering the character in isolation is possible on every
such device _except_ ascii.

> Does these files being separate serve some purpose, or is it an
> evolutionary accident?

If I tilt my head far enough to one side I can imagine a world where you
use tty.char when you're trying to test a document in some kind of
device-independent way, and you use tty-char.tmac when you need
"practical" rendering.

But for that scenario to hold, practically all fallback character
definitions need to move from tty.tmac to tty-char tmac.

Doing that would also be in tension with that I think was a historical
effort (in groff) to characterize "nroff" as being training wheels for
AT&T *roff refugees.  The idea was, I think to steer everyone to the
groff(1) front end for one-stop shopping.  Perhaps the notion was to
someday deprecate nroff in favor of groff's grand unification of data
flow.  And man-db(1) man seems to honor that intention.

However, adding features like output character encoding detection to
nroff(1) stymied that objective, and nroff's unconditional loading of
tty-char.tmac compounded the...stymieing.

I personally find groff's nroff command to be useful and a
keystroke-saver.

There also remains the matter of "fallbacks.tmac", which at least
documents its purpose as "generic", by which I think we are to assume
output-driver independent.

So that's a lot of words to tell you that I don't have a good answer.

The comments at the tops of fallbacks.tmac and tty-char.tmac do appear
to articulate coherent objectives, but I'm not sure we (and I include
myself in that pronoun since I've mucked about with both) have hewed to
them as reliably as we should.

Colin Watson's feedback as man-db maintainer might be helpful here.

Regards,
Branden

signature.asc
Description: PGP signature