[bug #64484] [troff] .device and \X should behave similarly

[G. Branden Robinson]

Update of bug #64484 (group groff):

                  Status:               Postponed => In Progress            
                 Summary: [troff] \X escape sequence should read its argument
in (something like) copy mode => [troff] .device and \X should behave
similarly

    _______________________________________________________

Follow-up Comment #21:

Restoring original summary, more or less, and un-postponing.

1.  \X should encode special characters in its argument in `\[uXXXX]` form. 
This is done.

2.  The `device` request should do the same.

3.  Neither `\X` or `device` should cause a blanket flush of 5 different
things:


   set_font(tf);
   glyph_color(gcol);
   fill_color(fcol);
   flush_tbuf();
   do_motion();


Right now they both do, and this causes documents to regress.  People have
undertaken baffling workarounds like:


.      nop \!x X ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title (\\*[pdf:title])
/Level \\n[pdf:bm.lev] /OUT pdfmark


...which really should be expressible as:


.      device ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title (\\*[pdf:title])
/Level \\n[pdf:bm.lev] /OUT pdfmark


(That's from "pdf.tmac"'s `pdfbookmark` macro definition, which is why the
backslashes are doubled.)

Extend the `fl` request to take letter arguments encoding which bits of state
should marked dirty, or flushed, depending on how you look at it.

f set_font()
m glyph_color()
M fill_color()
t flush_tbuf()
p do_motion()

These aren't the world's best mnemonics.  Lots of collisions here:
font/fill/flush, m/M/motion.  But we need _something_.

Maybe we can read an "identifier" (word) at a time and `strcmp()` it.  That'd
be less gross.

Most device extension commands won't need to perform a flush, because they
don't dirty any of these states.  sboxes is an exception.  But all it needs to
dirty is the fill color (and _maybe_ the glyph color, because of the box
edges?)...but not the rest.  `do_motion()` in particular appears to cause
grief, and breaks Peter's _mom_ documents, unaligning the shaded boxes with
the text that's supposed to be in them.

Possibly once all this is done we won't need the long-undocumented `tag` and
`taga` ("tag append") requests anymore.  I get the feeling they were stuck in
to avoid the state-flushing problems described above.  One bit I don't
understand is what's being "appended": both write out "x X" commands,
seemingly right away.  `taga` has very limited use: one invocation in
"devtag.tmac", which calls it from one macro "DEVTAG-NEXT", which itself has
only one caller anywhere, "DEVTAG-COL-NEXT".  _me_ and _ms_ (and only those)
call that, but I don't know if columnated HTML output works with those
packages in the first place.  Find out.  If it doesn't, nothing is lost if we
"break" it.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64484>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature