[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[Deri James]

Follow-up Comment #22, bug#63074 (group groff):

Whew, rather a lot to cover!

First the original "bug" was "fixed" by including -f U-T in the command.

Next it became a wish to include non-latin character in the bookmarks. This is
now working on my branch, waiting for Branden's integration.

Then it became a discussion on Branden's for iterator being used as a
replacement for stringhex, and using it to send arbitrary bytes in device
control commands, and his recent discovery that you can already do this. My
statement in 2022 (see comment #11):-

"If I dropped the .asciify from pdf.tmac it would mean all the \[u]
strings would reach the post processor gropdf, which could then assemble a
UTF-16 string from the hex numbers."

Which is exactly what I have done in the new pdf.tmac/gropdf.

I think Branden has not fully grasped the reason why stringhex is required.
The problem lies in the original pdfmark API, if you look at the pdfmark.pdf
you will see that in the sections describing .pdfhref M and .pdfhref L which
both refer to a "dest-name" and "descriptive text", it says that if a
dest-name is not given the first word in the description is used as the
dest-name.

The macros create a string like:-

.ds pdf:look(\\*[dest-name]) descriptive text

Since descriptive text can include any groff escape this means that dest-name
may also include any groff escape occurring in the first word. The reason it
creates these string registers is to support mom features such as:-

.HEADING 1 NAMED Гуляйпольщина "Гуляйпольщина"
Гуляйпольщина (укр. Гуляйпольщина) или
Махновщина, также Вольная
Территория — повстанческий район в
Северном Приазовье в период
Гражданской войны 1918—1921 гг.
.PP
And so it goes on.
.PDF_LINK Гуляйпольщина PREFIX ( SUFFIX ) "see: +"

Where the "+" is replaced by the contents of the string register
pdf:look(Гуляйпольщина), which would actually be a string of
\[u] nodes, so would generate an error. This is what stringhex is for, to
hide the contents so that groff does not see it as a sequence of nodes. The
ideal solution would be to allow string registers to have an attribute (say
"glass") which signals that groff should never try to interpret its contents,
i.e. operate as if the escape mechanism was turned off just for the contents
of that register, and have a way of turning that attribute on/off or an escape
which sets the attribute for the enclosed string.

I don't know if this is helpful, and helps you understand why stringhex is
being used.


___

Reply to this item at:

  

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

[bug #64913] [PATCH] Makefile.am: variable "HOST" is not created by "automake"

[Dave]

Update of bug#64913 (group groff):

  Item Group:  Build/Installation => Documentation  
 Summary: Makefile.am: variable "HOST" is not created by
"automake" => [PATCH] Makefile.am: variable "HOST" is not created by
"automake"

___

Follow-up Comment #5:

Changing the Item Group: while the affected file is part of the build system,
the problem is only in comment lines, which serve to document, not to build.


___

Reply to this item at:

  

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

[bug #57747] Malfunctioning romanian special characters

[Dave]

Update of bug#57747 (group groff):

  Status:   Need Info => Unreproducible 
 Assigned to:None => barx   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

As the submitter has not responded in nearly four years, and Deri (gropdf
maintainer) offered a solution to the likeliest source of the problem, I'm
closing this bug report.  Original submitter, if you are still having issues
with this, please post a comment here, and the bug report can be reopened.


___

Reply to this item at:

  

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

[bug #59962] soelim(1) man page uses pic diagram--should it?

[Dave]

Follow-up Comment #7, bug#59962 (group groff):

Helge, do you have any response to comment #6 here?

In particular, it's still unclear what the "separate file" is that you
reference in item 4 of comment #4, or whether this is something that warrants
keeping this bug open, since that comment also stated that item 4 could be
disregarded.


___

Reply to this item at:

  

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

[bug #61052] .version file not updated as aggressively as it should be

[Dave]

Follow-up Comment #15, bug#61052 (group groff):

[comment #8 comment #8:]
> full reasoning can be found at
> https://lists.gnu.org/archive/html/groff/2022-03/msg00051.html.

Quoting Branden from this March 2022 message: "Savannah #61502 can be reopened
and re-resolved with instructions and a pointer to the `git-version-gen`
script."

But Branden may have later had second thoughts about this re-resolution: he
set this bug to "Need Info" status on June 15, 2022 (with the mysteriously
blank comment #10), but it's unclear what info is being sought.  The
mailing-list discussion linked to in comment #12 happened in that same time
frame, so that might be related.  Bruno's last post in the thread
(http://lists.gnu.org/r/groff/2022-06/msg00090.html), from June 19, addresses
some questions posed earlier, but there is no follow-up to this message.

Branden, when you get a chance, can you clarify what info, if any, is still
needed to resolve this bug?


___

Reply to this item at:

  

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

[bug #52463] anything that talks to standard error should identify itself

[G. Branden Robinson]

Update of bug#52463 (group groff):

  Depends on: => bugs #57611


___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Update of bug#63074 (group groff):

  Status: In Progress => Need Info  

___

Follow-up Comment #21:


[comment #20 comment #20:]
> I'll bolster the unit tests I have pending to make sure this works okay for
all output devices.

Bolstered and confirmed.

Setting ticket to "Need Info" status to solicit feedback from Deri in
particular, and anyone else who wants to comment.


___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Follow-up Comment #20, bug#63074 (group groff):

Sleeping on the problem provoked illumination, as it sometimes does.

In any other _roff_ context, how would we smuggle something that looks like an
escape sequence into a different interpretation context?

By escaping it.


$ cat
EXPERIMENTS/device-control-request-with-double-escape-special-character-and-partially-collected-line.roff
.device ps: nop \\[u007E]
.br
$ groff -Z
EXPERIMENTS/device-control-request-with-double-escape-special-character-and-partially-collected-line.roff

x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X ps: nop \[u007E]
n12000 0
x trailer
V792000
x stop
$ cat
EXPERIMENTS/device-control-escape-sequence-with-double-escape-special-character.roff
\X'ps: nop \\[u007E]'
$ groff -Z
EXPERIMENTS/device-control-escape-sequence-with-double-escape-special-character.roff
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X ps: nop \[u007E]
n12000 0
x trailer
V792000
x stop


I get the same output from _groff_ 1.22.4, 1.23.0, and Git HEAD.

This feels like a win.  Needs some discussion in documentation as the
assumption of many users may be "you can't do that".  And to mention the fact
that it's up to the postprocessor to interpret the syntax (and even then
possibly only in the context of a specific device control command).

I'll bolster the unit tests I have pending to make sure this works okay for
all output devices.


___

Reply to this item at:

  

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