[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

Update of bug#64071 (group groff): Assigned to:gbranden => None ___ Reply to this item at: ___ Message s

[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

URL: Summary: [troff] support construction of arbitrary byte sequences in device control commands Group: GNU roff Submitter: gbranden Submitted: Mon 08 Jan 2024 10:13:02 AM UTC

[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

Follow-up Comment #1, bug#65137 (group groff): This isn't a strict dependency, but see bug #64484. ___ Reply to this item at: ___ Message sent via Savan

[bug #65138] [troff] `device` request silently fails before first page begins

URL: Summary: [troff] `device` request silently fails before first page begins Group: GNU roff Submitter: gbranden Submitted: Mon 08 Jan 2024 10:37:59 AM UTC Category: Core

[bug #64484] [troff] .device and \X don't behave the same

Follow-up Comment #5, bug#64484 (group groff): Another oddity is that you can invoke the `device` request too early, and it won't be honored, but can use `\X` anywhere you want. $ cat EXPERIMENTS/device-control-escape-sequence.roff \X'ps: nop' $ ~/groff-stable/bin/groff -Z EXPERIMENTS/device-con

[bug #64484] [troff] .device and \X don't behave the same

Follow-up Comment #6, bug#64484 (group groff): [comment #5 comment #5:] > Another oddity is that you can invoke the `device` request too early, and it won't be honored, but can use `\X` anywhere you want. This turns out to be due to the presence of a break on a line using the \X escape sequence,

[bug #64484] [troff] .device and \X don't behave the same

Follow-up Comment #7, bug#64484 (group groff): My last paragraph in comment #6 was a bit mangled. Let me try that again. The foregoing means that I should abandon my plan to make a new fatal error in response to bug #65138 and also that the scenario in question is probably a corner case. Genera

[bug #65138] [troff] `device` request silently fails before first page begins

Update of bug#65138 (group groff): Item Group: Warning/Suspicious behaviour => Documentation ___ Follow-up Comment #1: A partially collected line needs to exist at least once. If it does, you can issue a `device` r

[bug #65138] [troff] `device` request silently fails before first page begins

Follow-up Comment #2, bug#65138 (group groff): Trying again with the verbatim bit. $ cat EXPERIMENTS/device-control-request-and-nothing-else.roff .device ps: nop $ groff -ww -Z EXPERIMENTS/device-control-request-and-nothing-else.roff x T ps x res 72000 1 1 x init p1 x trailer V792000 x stop $ ca

[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

Update of bug#65137 (group groff): Status:None => Duplicate Assigned to:None => gbranden Open/Closed:Open => Closed ___

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

Update of bug#63074 (group groff): Status:None => In Progress Assigned to:None => gbranden Summary: [troff] need a way to embed non-Basic Latin glyphs in device control commands => [t

[bug #64959] [troff] add unit tests for `device` and `output` requests

Update of bug#64959 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #1: [comment #0 original su

[bug #64959] [troff] add unit tests for `device` and `output` requests

Follow-up Comment #2, bug#64959 (group groff): [comment #1 comment #1:] > Being dealt with in bug #65118. Nope. Bug #65138. ___ Reply to this item at: ___

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

Follow-up Comment #19, bug#63074 (group groff): Tricky. By the time `encode_char` sees the input it has already been tokenized. This means that what is of interest for my approach is a "token" node, and that in turn means that input that looks like \X'\[u007E]' has already effectively been r