synchronous and asynchronous grout (was: Novel use of .char)

[G. Branden Robinson]

Hi Deri,

I'm going to quote your whole presentation (omitting quotes of myself)
because it is a tour de force of explication.

At 2024-12-18T00:19:28+0000, Deri wrote:
> The model I use to understand the difference between \X and \!
> (.device and .output) is that one uses an in-band channel (\X) and the
> other is side-band.  The in-band stream is the majority of data which
> must be output in chronological order so follows the order of commands
> in the document, i.e.:-
> 
> \m[red]Word\m[]
> 
> Must arrive on the in-band channel in this precise order:-
> 
> SetCol red
> Text Word
> RestoreCol
> 
> Any other order would be wrong. This is what I mean about maintaining
> a chronological order. The issue Peter discovered showed the vertical
> movement which should have appeared in the stream before \X was
> appearing after it.
> 
> Conversely sideband instruction are usually treated like an interrupt,
> they are executed immediately. An example:-
> 
> $ printf "Init\n.br\n\X'First'Second\n.output x X Third" \
>   | test-groff -Z
> x T ps
> x res 72000 1 1
> x init
> p1
> x font 5 TR
> f5
> s10000
> V12000
> H72000
> md
> DFd
> tInit
> n12000 0
> x X Third
> V24000
> H72000
> x X First
> V24000
> H72000
> tSecond
> n12000 0
> x trailer
> V792000
> x stop
> 
> You can see that "Third" appears first because it was sent as a
> side-band message, so I am not concerned with the chronology, I want
> it to go to the driver right away. It is primarily useful for sending
> meta-data to the driver.
[...]
> What you are describing here is the in-band processing, you have not
> covered the side-band processing troff does. Let's look at what .pline
> tells us:-
> 
> $ printf "Hello\c\n.output x X You little beauty\nWorld\c\n.pline" \
>   | test-groff -Z
> x T ps
> x res 72000 1 1
> x init
> p1
> x X You little beauty
> {type: line_start_node, diversion level: 0},
> {type: glyph_node, character: "H", diversion level: 0},
> {type: glyph_node, character: "e", diversion level: 0},
> {type: glyph_node, character: "l", diversion level: 0},
> {type: glyph_node, character: "l", diversion level: 0},
> {type: glyph_node, character: "o", diversion level: 0},
> {type: transparent_dummy_node, diversion level: 0},
> {type: kern_pair_node, diversion level: 0},
> {type: glyph_node, character: "r", diversion level: 0},
> {type: glyph_node, character: "l", diversion level: 0},
> {type: glyph_node, character: "d", diversion level: 0}
> x font 5 TR
> f5
> s10000
> V12000
> H72000
> md
> DFd
> tHelloW
> H102860
> torld
> n12000 0
> x trailer
> V792000
> x stop
> 
> Notice that the .output directive never made it to the node list,
> because it has been actioned immediately. I hope this model helps you
> to better understand how the device control commands work in groff.

This is an extremely helpful presentation.  I have some questions.

1.  Where was the foregoing distinction documented in, say, the groff
    1.22.3 era?

2.  How confident are you that these distinctions were consciously
    designed in, and to what _extent_ do you think that was the case?
    Are they (or were they, back in groff 1.22.4 and earlier) consistent
    between .devicem and \Y as well?

3.  I want to understand one of your applications better.

> I am not concerned with the chronology, I want it to go to the driver
> right away. It is primarily useful for sending meta-data to the
> driver.

Sometimes you want to get a device command out to the grout stream right
away, while an output line is still being collected.  Okay.  When does
this happen?

It is perhaps a failure of my imagination, but I tend to think of device
control commands as either being setup-related, or as working somewhat
like XML tags, in that we want to bracket some conventional grout
commands with some changes of state not captured in the grout language
but which are relevant to the output device.  (An example that comes to
mind is "hotspot starts here" and "hotspot ends here".)

I am having a hard time thinking of a case where synchronous embedding
of a device command _isn't_ desirable, or wouldn't work just as well.
Say, for instance, that we saw something on the input that told us we
needed to change the input tray for the next page (to switch to a
different paper stock, maybe).

We might have this.

$ printf "0\n.br\n\X'First'Second\n.output x X tray: cardstock\nThird" \
  | test-groff -Z
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
t0
n12000 0
x X tray: cardstock
V24000
H72000
V24000
H72000
x X First
tSecond
wh2500
tThird
n12000 0
x trailer
V792000
x stop

I could also do this.

$ printf "0\n.br\n\X'First'Second\n\X'tray: cardstock'\nThird" | tg -Z
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
t0
n12000 0
V24000
H72000
V24000
H72000
x X First
tSecond
wh2500
V24000
H103940
x X tray: cardstock
wh2500
tThird
n12000 0
x trailer
V792000
x stop

And the change in the grout command sequence is precisely as you
describe.

But both would get the same job done.  Under what circumstances do I
only learn in the course of formatting an output line that the output
device needs to know something before I _start_ writing out that line,
and yet that same something is not coupled to any particular glyph or
motion (or sequence thereof) on that output line?  And when is that
knowledge something that couldn't have been known by the document and
expressed in the input language at an appropriately early time?

Thanks for your patience with my questions.

Regards,
Branden

signature.asc
Description: PGP signature