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

[G. Branden Robinson]

[discussion moved to groff@ which is a discussion list; I feel that
bug-groff@, like groff-commit@, is not--Reply-To set accordingly]

At 2024-09-22T18:40:46-0400, Dave wrote:
> Branden wrote in bug #66233:
> 
> > It feels to me more like the alternation of renderings as
> > "tty-char" does should be controlled by a device-specific
> > register instead of by selective load of a macro package that
> > _nroff_ defaults to performing.  The latter technique messes up
> > _nroff_'s orthogonality, in my opinion.
> 
> Ingo opposed using a register in comment #3, hence I wrote my proposed
> patch to make grotty load tty-char.tmac unconditionally (not just when
> the nroff script is used to launch it), but in a way that allows it to
> be easily disabled if desired, per subsequent discussion with Ingo.
> I'm not married to this approach, but there has thus far been no
> objection to it, and I do strongly agree with his point from comment
> #1: "i think most users would be better served by loading
> [tty-char.tmac] by default."

Okay.  I guess I mildly disagree with a lot of the discussion up to this
point, then.

Registers are perfectly idiomatic in *roff.  They're not heavyweight.

It's a little unusual to use them to configure output driver behavior,
but on the other hand before groff came along I suppose it was unusual
to have driver-specific macro files too.  That precedent is now solidly
established.

My objection to the definitions in "tty-char.tmac" is one that applies
only in some circumstances but it's a fairly strong one when it does: it
is that they're not great if someone has used some of the characters
that get replaced in tables.

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.

.tty-char \[ca] <intersection>
.tty-char \[*e] <epsilon>
.tty-char \[mo] <element\~of>

I acknowledge that Ingo's semantic substitutes from about 7 years ago:

commit f9dc2ae1296be719424da027f2cff0a4f1a4623c
Author: Ingo Schwarze <schwarze@usta.de>
Date:   Fri Aug 25 23:14:18 2017 +0200

    `tty-char.tmac': focus on meaning rather than graphical shape

    * tmac/tty-char.tmac: add ASCII renderings for six missing
    mathematical symbols

...are useful--in _some_ circumstances.  Most often where the text isn't
carefully laid out.  In other words, when it's being filled.  When the
layout is flexible, they are surely much more communicative of meaning,
which is a valuable trait.

So I like the fact that these character redefinitions are conditional.

But I also think that adopting them wholesale (or not) for the entire
lifetime of a document is not so good.

I notice that in "tty.tmac", fallback characters generally produce an
"expansion" of no more than 3 ens in width.  In other words, any given
character will only "bloat" by 2 ens at worst if substituted.  That
also seems like a useful property to me, and one we could document and
advise users of.

So, yeah, I would "engineer" them behind a register gate: call it
"tty*use-semantic-substitutes" or something.  Then document authors
could swap these substitutions in and out.  Maybe even by doing
something like this:

.\" my fancy document
.am TS
.  nr tty*use-semantic-substitutes 0
..
.
.am TE
.  nr tty*use-semantic-substitutes 1
..
.
.nr tty*use-semantic-substitutes 1
.
.PP
Let us consider each of Euclid's thirteen books of the
.I Elements
in exhaustive detail.

> I'm not sure if Branden's remarks constitute an objection, because I'm
> not sure what orthogonality is being messed up,

The axes that I regard as orthogonal are:

1.  a user's decision to use "nroff" to figure out the correct choice of
    groff terminal output device;

and

2.  a user's preference of whether the "visual" vs. "semantic" fallback
    character definitions are used.

> and thus whether or not that applies to my proposal.

I hope this sheds some light.

Regards,
Branden

signature.asc
Description: PGP signature