[bug #62264] [troff] string iteration handles escape sequences inconsistently (want `for` request)

[Deri James]

Follow-up Comment #5, bug #62264 (project groff):

As you may be aware one of the goals for the new version of gropdf I have been
working on is to make it "friendlier" for unicode support. To do this I had to
drop using asciify and pass the original string to gropdf since the special
chars such as \[uXXXX] produced by preconv cannot be asciified and just
disappear, whereas gropdf (which has access to the font information) can
convert this to utf16. This is now all working.

One problem remains. In Keith's pdfmark macros (upon which pdf.tmac is based)
he introduced the convention that when placing a link in the document to an
internal destination within the document using:-

.pdfhref L [-D <dest-name>] [-P <prefix-text>] [-A <affixed-text>] \
[-X] [--] [descriptive text ...]

If "Descriptive text" is missing it will be replaced with text from when the
target destination is created. In pdf-mom.pdf this concept is explained as
"expandos" (+ and *). What this means is that the descriptive text used when
the destination is created is stored in a troff string register called
pdf:look(<dest-name>). The problem is that if the dest-name is not ascii, for
example, if the document is written in unicode cyrillic, it is natural that
the dest-name will be cyrillic as well. The problem is that if the name
includes unicode (\[uXXXX]) then you receive an error:-

error: special character is not allowed in an identifier

So, at the moment, all destinations must be given in ascii to avoid the error
occurring. I don't know whether the proposed change in this bug will help.

One simple solution would be a new request, .stringhex, a similar code to that
used in .stringup/down. This would effectively hide the special characters
within the string but still produce a unique identifier to be used as a
dest-name in the pdf:look() register.

Or is there a better way of solving this problem.



    _______________________________________________________

Reply to this item at:

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

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