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

[G. Branden Robinson]

Update of bug #64484 (project groff):

                  Status:               Need Info => None                   

    _______________________________________________________

Follow-up Comment #3:


[comment #2 comment #2:]
> There are 4 separate ways to send text to a postprocessor.

Thanks, Deri.  I've documented all of these but did not consider them this
way.  This is good stuff.

> \X is the only one which attempts to "asciify" the parameters.

Yes.  My instinct it to change this so that the `device` request does the same
processing as `\X`.

> There is a difference between the two pairs of commands, if you remove the
.fl and rerun:-

> x T ps
> x res 72000 1 1
> x init
> p1
>  ! \(ti deri
> output \(ti deri
> tm \(ti deri
> V12000
> H72000
> x font 5 TR
> f5
> s10000
> V12000
> H72000
> md
> DFd
> x X X ~ deri
> wh2500
> V12000
> H74500
> x X device \(ti deri
> n12000 0
> x trailer
> V792000
> x stop


> .output and \! are now out of chronological order.

This is well worth studying.  I think that thanks to you we have at last
identified a use case for the `fl` request in GNU _troff_ (as opposed to AT&T
_nroff_, where it had an application in interactive use).  I've seen macro
packages use it pointlessly.

> In gropdf I used to rely on manual "asciifying" of parameters, the new
gropdf does not, in order to support unicode (passed as \[uXXXX]) I need it to
be passed untouched.
>
> so it can be converted to UTF-16 by gropdf itself (also applies to any
special chars - \(xx \[xxx] \C'xxx' \N'nnn'). It also needs to maintain
chronological order.

I think we might be in for some design changes here in the 1.24 cycle.

TANAKA Takuji's patches to _grops_ in bug #62830 have what look to me like
similar concerns regarding the production of UTF-16 by the output driver.

> I don't know whether the pdfmark macros rely on the asciifying behaviour of
\X or not.

I don't either.

I'd like `device` and `\X` to be counterparts, as `output` and `\!` appear to
be.

Even better would be for `sy`, `tm`, and other requests that access the
standard error stream or the file system to use the same mechanism for
encoding characters.  See bug #64071.

This stuff is going to require some thought.


    _______________________________________________________

Reply to this item at:

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

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