[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed: make \X read its argument in copy mode
|
From: |
G. Branden Robinson |
|
Subject: |
Re: Proposed: make \X read its argument in copy mode |
|
Date: |
Fri, 19 Jan 2024 19:39:21 -0600 |
[self-follow-up with correction]
At 2024-01-19T18:56:37-0600, G. Branden Robinson wrote:
> This might be more accurately stated as:
>
> 2) \X behaves like .device used to (in groff 1.23.0 and earlier).
[correction follows]
And I repeat: this is _NOT_ a _hard_ prerequisite to expressing Unicode
sequences in the output, but it seems useful so that authors of output
drivers (and supporting macro files for them) can keep their sanity.
[elaboration]
What I mean is that we can pass Unicode between "pdf.tmac" and the
output driver _today_. Consider the following notional macro.
.de pdfmark2
. nop \!x X ps:exec [\\$* pdfmark2
..
(The open bracket has something to do with PostScript syntax, I think.)
...and it getting called by some other macro encoding the argument...
.de pdflink
. ds pdf*input \\$*\"
. encode pdf*input \" performs magic transformation, like "stringhex"
. pdfmark2 \\*[pdf*input]
..
...and I have document using these.
.H 1 "This is my heading"
.pdflink "HI DERI 😈"
This ultimately would show up in the output as something like this.
x X ps: exec [4849204445524920F09F9888 pdfmark2
Something pretty close to that works on the deri-gropdf-ng branch today,
as I understand it.
But my _suggestion_ would be that we support something more like this.
x X ps: exec [HI DERI \[u00F0]\[u009F]\[u0098]\[u0088] pdfmark2
or this...
x X ps: exec [HI DERI \[uDE08]\[uD83D] pdfmark2
...or even this...
x X ps: exec [HI DERI \[u1F608] pdfmark2
These are groffish ways of expressing UTF-8, UTF-16LE, and UTF-32,
respectively. The reuse of groff Unicode code point escape sequence
syntax is, I would hope, more helpful than confusing.
My concerns are that (1) people don't have to use two different escaping
conventions _within the formatter_ to get byte sequences to the output
driver, and (2) that driver-supporting macro file writers don't have to
handle a bunch of special cases in device control commands.
Those factors are what drive my proposal.
Regards,
Branden
signature.asc
Description: PGP signature