[bug #66187] [troff] permit control over flushing of output file state

[G. Branden Robinson]

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