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.robin...@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. >
