[bug #66165] commit dcae60b0fb1ad3fa3314fdfdbecb973961a40410 has wrong assumption

[G. Branden Robinson]

Update of bug #66165 (group groff):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #1:

Hi Deri,

Afraid to say I disagree with you here.

[comment #0 original submission:]
> It assumes that all \X parameters end up as meta-data but this not the
case,

It's metadata by definition from _troff_'s perspective.  The formatter has no
idea what the output driver is going to require, but *does* need to have a way
to *encode* that "whatever is required", and my objective is to *not* have
different encodings for `\X` arguments (and `device` requests, and `\!` escape
sequences, and `cf` and `trf` requests) depending on the identity of the
output driver.

> troff has no knowledge of the purpose of the data.

I agree with you there.  That's why a single representation format should be
used.  (Albeit a bowdlerized one accepting only the first 128 or, *maybe* 256
code points when "going external" not to an output driver, but to a POSIX
narrow-character standardized function like _fprintf_(3), _fopen_(3), or
_system_(3).  See bug #62787, bug #64071, and bug #65108.)

> For example, grops accepts:-

> \X'ps: exec code'


> Where "code" can be a postscript program:-

> [derij@pip Branden (master)]$ echo "\X'/R { moveto 0 SC 3 -1 roll X
widthshow Y } def'"|test-groff -Z| grep "^x X "
> x X /R { moveto 0 SC 3 \[u2010]1 roll X widthshow Y } def


> Sometimes the "data" is a filename:-

> [derij@pip Branden (master)]$ echo ".PSPIC -L dark-red.eps"|test-groff
-Z|grep "x X "
> x X ps: invis
> x X ps: endinvis
> x X ps: import dark\[u2010]red.eps 0 0 81 96 81000 


> Since troff cannot know what the data is going to be used for it is unsafe
for troff to change the data in this way.

I'd say it's _more_ unsafe to pass unencoded bytes through as-is.  We don't
know what those bytes are going to be used for.  Recall that we have a
terminal output driver.  Then consider
[https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emulators-with-ansi-escape-characters
cases like this].

I think the output driver is well situated to perform whatever transformation
it needs on groff-style-Unicode special character escape sequences, given the
context, which it's going to know better than the formatter, and might vary
from one device extension to another.

I'm going to need additional opinions on this.


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature