URL: <https://savannah.gnu.org/bugs/?66187>
Summary: [troff] permit control over flushing of output file
state
Group: GNU roff
Submitter: gbranden
Submitted: Sun 08 Sep 2024 05:16:45 AM UTC
Category: Core
Severity: 1 - Wish
Item Group: Feature change
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Sun 08 Sep 2024 05:16:45 AM UTC By: G. Branden Robinson <gbranden>
As recently discussed on the mailing list, when _troff_ features that wrap
device extension commands (meaning: the `\X` escape sequence and `device`
request) run, they end up calling the following function.
void troff_output_file::start_special(tfont *tf, color *gcol,
color *fcol,
bool omit_command_prefix)
{
set_font(tf);
stroke_color(gcol);
fill_color(fcol);
flush_tbuf();
do_motion();
if (!omit_command_prefix)
put("x X ");
}
This function does a lot.
It updates the state of the selected font, stroke and fill colors, and drawing
position. These all map to device-independent output commands ('f', 'm', 'D
F', and 'H' and 'V', respectively).
A device extension command may influence none, some, or all of these.
Hence all the function arguments, right?
Well, no. There's no means in the _groff_ language (nor of Kernighan _troff_
before it) of expressing *which* of these should be updated before or after a
device extension command.
So, basically, this function resets everything.
For one thing, that's inelegant, and leads to pointless _grout_ commands
appearing in the output stream.
For another, and much worse, this means you _can't_, from the _groff_
language, _tell_ the formatter that your device extension command has, say,
done something that has "dirtied" the state of the stroke and/or fill colors,
and that these should be restored, say _after_ the device extension command
(not before).
So what I'd like to do is extend the little-used `fl` request to accept
arguments (CSTR #54 `fl` accepts none).
These arguments would encode each of the foregoing data:
* font selection
* stroke color selection
* fill color selection
* horizontal drawing position
* vertical drawing position
Consequently I propose a new idiom for use of `\X` and `device`: bracket these
formatting directives with `fl` requests if and as necessary.
If a device extension command does nothing to affect the state of page output
operations--whimsically we might imagine causing a message like "HELLO, DAVE"
to appear on a printer's LCD display--then just like now it need not invoke
any `fl` requests.
Importantly, none of these arguments is parameterized. The idea is not to
replace formatter operations but to ensure synchrony between formatter state,
representation of that state in device-independent output, and the state of
the device.
So when you "flush" any of these data, the parameter written to the
device-independent output is what the formatter _thinks_ it is at that moment.
If your device extension command really does do something like change the
stroke color, you'll need to encode that in your input alongside the `\X` or
`device` instruction.
I'll be updating this ticket with a demonstrator involving Deri's "sboxes"
package, which is what brought this issue to my attention.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66187>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
