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/
