Re: Proposed: make \X read its argument in copy mode

[John Gardner]

Hi Branden,

So instead of:
> \X'ps: \fB\s(12\m[red]big bold red text in my device command\fP'
>
> one would write:
> \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP


I believe you meant to provide an example more like this?

\X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont
setfont (Text) show'

Regards,
— John


On Wed, 17 Jan 2024 at 06:23, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Or: Should device control commands affect the environment?
>
> Recall the definition of the \X escape sequence from CSTR #54 (1992).
>
>   10.7.  Transparent output.  The sequence \X'anything' copies anything
>   to the output, as a device control function of the form x X anything
>   (§22).  Escape sequences in anything are processed.
>
> The foregoing doesn't say anything about copy mode.  This has a
> brow-raising consequence.
>
> Consider the following input.
>
> $ cat backslash-X-affects-environment.roff
> .sp
> .tm .f=\n(.f
> \X'\fB'
> .tm .f=\n(.f
>
> Documenter's Workbench 3.3 troff, Heirloom Doctools troff, and GNU troff
> all produce the same output to the standard error stream.
>
> .f=1
> .f=3
>
> What they produce as device-independent output might be even more
> interesting.
>
> $ DWBHOME=. ./bin/troff backslash-X-affects-environment.roff \
>   | grep '^x X'
> .f=1
> .f=3
> x X
>
> $ ./bin/troff backslash-X-affects-environment.roff | grep '^x X'
> .f=1
> .f=3
> x X LC_CTYPE en_US.UTF-8
> x X
>
> $ ~/groff-stable/bin/groff -Z ./backslash-X-affects-environment.roff \
>   | grep '^x X'
> .f=1
> .f=3
> x X
>
> Nothing.
>
> So "anything" doesn't exactly make it to the output as a device control,
> "transparently" or otherwise.  This is because a handful of escape
> sequences, like \f, \s, and the GNU extensions \m and \M (which set the
> stroke and fill colors, respectively) are never turned into nodes by the
> tokenization process; instead, (when not in copy mode) they immediately
> alter the current environment.
>
> Another thing to know is that there is no such thing as an environment
> in troff's output language.  Changes to the environment manifest as one
> or more other output commands, like 'f' for font selection, or 's' to
> set the type size.
>
> This foregoing exhibits seem like evidence of a design wart to me.  On
> no *roff do such escape sequences survive to device independent output;
> they can't, because they have no (direct) representation there.
>
> I therefore propose to change this, and have the `\X` escape sequence
> read its argument in copy mode.  That will make it work like the
> `device` request in groff 1.23.0 and earlier[1].
>
> Some things this wouldn't change:
>
> 1.  The ability to interpolate registers and strings inside device
>     control commands--which I would guess is the main reason "Escape
>     sequences in anything are processed" as CSTR #54 puts it--remains.
>
> 2.  The ability to affect the environment "simultaneously" with a device
>     control command remains possible; just put those escape sequences
>     _outside_ the device control escape sequence.
>
>    So instead of:
>
>    \X'ps: \fB\s(12\m[red]big bold red text in my device command\fP'
>
>    one would write:
>
>    \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP
>
>    ...though I am dubious that the former has ever been well-defined
>    as far as interactions with device operations go.
>
> Thoughts?  Objections?  Counterexamples?
>
> Regards,
> Branden
>
> [1] Earlier this week I pushed a change to make `device` read _its_
>     argument in interpretation, not copy, mode.  My second thoughts
>     about that are what prompted this proposal.
>
>     See <https://savannah.gnu.org/bugs/?64484> for background.
>