gropdf-ng merge status (was: PDF outline not capturing Cyrillic text)

[G. Branden Robinson]

Hi Deri,

Now _does_ seem to be a good time to catch up on gropdf-ng merge status.
There were two things I knew were still unmerged: the slanted symbol
(SS) font support and the stringhex business, which has larger
consequences than I understood at first.

At 2024-02-06T13:39:51+0000, Deri wrote:
> The current gropdf (in the master branch) does support UTF-16BE
> for pdf outlines (see attached pdf), but Branden has not released

At this point it's a merge (to the master branch), not a release, but
true with that caveat.

So let me take a crack at a code review.

diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index d3b5002a8..87d9ba3cb 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -4906,7 +4906,7 @@ y\R'#DESCENDER \\n[.cdp]'
 .    ds $AUTHOR \\*[$AUTHOR_1]
 .    substring $AUTHORS 0 -2
 .    ds PDF_AUTHORS \\*[$AUTHORS]
-.    pdfmomclean PDF_AUTHORS
+.    if '\\*[.T]'ps' .pdfmomclean PDF_AUTHORS
 .    nop \!x X ps:exec [/Author (\\*[PDF_AUTHORS]) /DOCINFO pdfmark
 .END
 .
@@ -23512,13 +23512,13 @@ No room to start \\*[MN-pos] margin note 
#\\n[MN-curr] on page \\n[#P].
 .          el .nr LEVEL_REQ \\n[CURRENT_LEVEL]
 .       \}
 .       ds PDF_TX \\$*
-.       pdfmomclean PDF_TX
 .       nr PDF_LEV (\\n[LEVEL_REQ]*\\n[#PDF_BOOKMARKS_OPEN])
 .       ie '\\*[.T]'ps' \{\
 .           if !'\\*[PDF_NM]'' \{\
 .              pdfhref M -N \\*[PDF_NM2] -- \\*[PDF_TX]
 .              if !dpdf:href.map .tm gropdf-info:href \\*[PDF_NM2] \\*[PDF_TX]
 .           \}
+.           pdfmomclean PDF_TX
 .           pdfbookmark \\n[PDF_LEV] \\*[PDF_TX]
 .       \}
 .       el .pdfbookmark \\*[PDF_NM] \\n[PDF_LEV] \\$*
@@ -23539,7 +23539,7 @@ No room to start \\*[MN-pos] margin note #\\n[MN-curr] 
on page \\n[#P].
 \#
 .MAC PDF_TITLE END
 .    ds pdftitle \\$*
-.    pdfmomclean pdftitle
+.    if '\\*[.T]'ps' .pdfmomclean pdftitle
 .    nop \!x X ps:exec [/Title (\\*[pdftitle]) /DOCINFO pdfmark
 .END
 \#

I hope to made "pdfmomclean" unnecessary with my revised fix for
Savannah #64484.[1]  Or at least enabled it to be shorter and simpler.

@@ -23612,8 +23612,10 @@ No room to start \\*[MN-pos] margin note #\\n[MN-curr] 
on page \\n[#P].
 .    if '\\*[PDF_AST]'*' \{\
 .        chop PDF_TXT
 .        ie '\\*[.T]'pdf' \{\
-.           ie d pdf:look(\\*[PDF_NM]) \
-.               as PDF_TXT 
\&\\*[PDF_AST_Q]\\*[pdf:look(\\*[PDF_NM])]\\*[PDF_AST_Q]
+.           ds PDF_NM_HEX \\*[PDF_NM]
+.           stringhex PDF_NM_HEX
+.           ie d pdf:look(\\*[PDF_NM_HEX]) \
+.               as PDF_TXT 
\&\\*[PDF_AST_Q]\\*[pdf:look(\\*[PDF_NM_HEX])]\\*[PDF_AST_Q]
 .           el \{\
 .               as PDF_TXT Unknown
 .               if !rPDF_UNKNOWN .tm \

In our discussions, significant confusion (mostly mine, I guess) has
surrounded "stringhex".  There are two distinct problems, as I
understand it.

1.  To date in groff development, PDF bookmarks generally get named
    using the text they're associated with.  In macro packages there is
    a tendency to keep track of the bookmarks by defining strings for
    them.  That's not a problem.  The problem is that the associated
    text is made _part of the string identifier_ (probably because this
    [a] is easy to implement and [b] results in O(1) lookup time given
    the way the formatter manages *roff strings).  The trouble is that a
    special character escape sequence is not valid in a *roff
    identifier.

    So while "pdf:look(ABC)" is a valid identifier,
    "pdf:look(\[*a]\[*b]\[*c])" is not, and Unicode special character
    escape sequences are no different.

    In my opinion, it is not a good design to encode the bookmark text
    directly into the name of the *roff identifier like this.

    A.  We have the problem above.

    B.  How do you ensure uniqueness of these strings?  What if I have
        multiple places in a document titled, say "Exercises"?

    An alternative approach would be to store the bookmark IDs in
    strings indexed by a serial number.  A *roff autoincrementing
    register is an obvious mechanism for doing this.  When you need to
    look up the bookmark, you call a macro that searches the collected
    ideas until a match is found.

    Back-of-napkin sketch:

    .\" Search for bookmark text matching $1.  Find matching bookmark
    .\" number in pdf*found if found, otherwise -1 for failure.
    bookmark if found, -1
    .de pdf:look
    .  nr pdf*found -1
    .  nr pdf*search-index 0 1
    .  while (\\n+[pdf*search-index] < \\n[pdf*max-index])
    .    if '\\*[pdf*bookmark!\\n[pdf*search-index]'\\$1' \{\
    .      nr pdf*found \\n[pdf*search-index]
    .      break
    .  \}
    ..

    Yes, this is an O(n) search and yes, we still have the uniqueness
    problem.

    Still another approach is to hash the bookmark identifier in some
    way, and that is more or less what you're doing with `stringhex`.
    (Strictly, it's not a hash, but an encoding.)  This is back to O(1)
    lookup time, which is good, but I regret the obfuscation of the
    bookmark text/identifier.  Also, if you pass that identifier to the
    device, the encoding has to be reversed.

    This leads us to the other problem...

2.  Getting Unicode code points _that aren't intended to be formatted as
    text_ to an output device has proven to be a devilish problem.

    For example, what does:

    \X'pdf: bizzarecmd \[u1234]'

    _mean_?

    Fortunately, I think this issue is fairly well in hand.  In Savannah
    #64484 we've agreed that representing non-ASCII data in the form of
    groff Unicode special character escape sequences is a defensible
    choice.  It might be misleading to the novice, though.  In a device
    control command this is simply a notational convention; the
    formatter doesn't take these and "turn them into" a Unicode glyph.
    Their interpretation is entirely up to the postprocessor.  But since
    that's true of device control commands by definition, this doesn't
    seem like a huge concession.

    I've had my work on `device` and `\X` on the back burner for about a
    week, but I will return to it.

diff --git a/font/devpdf/DESC.in b/font/devpdf/DESC.in
index 5cb254f37..a40a79b8d 100644
--- a/font/devpdf/DESC.in
+++ b/font/devpdf/DESC.in
@@ -7,5 +7,6 @@ sizes 1000-10000000 0
 styles R I B BI
 family T
 fonts 8 0 0 0 0 0 0 S ZD
+use_charnames_in_special
 tcommand
 postpro gropdf

This is a somewhat starting application of this directive given its
original design and intention.  I won't knock it if it works, but we
might need to rename it and rewrite its description.

Or, maybe we need a new directive.  At present,
"use_charnames_in_special" implies that the output device can render
_any_ Unicode code point.  So, if you use it in PDF, it might be turning
off some checks for glyph availability in the device's fonts.  Robin
complained of all those warnings about code points unsupported by the
device.  It would seem to be worse to fail to render them (because you
haven't installed fonts with the right coverage) _and_ fail to warn.

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index f7fc229cd..be566bd46 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -217,6 +217,4098 @@ my %StdEnc=(
     251 => 'ss',
 );
 
+my %AGL_to_unicode = (
+  "A", "0041",
+  "AE", "00C6",
+  "AEacute", "01FC",
+  "AEmacron", "01E2",

I am really not happy with this as a medium- to long-term solution.
4,100 lines of yet another Unicode mapping table.  We already have this
in src/utils/afmtodit/afmtodit.tables.  I think it would be better to
either:

A.  Construct gropdf.pl at build time using a gropdf.pl.in without it,
    and textual inlining of the foregoing afmtodit file (which already
    uses Perl syntax); or
B.  Just _ship_ the danged old afmtodit.tables, probably under a more
    general name, and have afmtodit and gropdf read it at run time.

4,100 lines of Repeating Ourselves sure does pinch.

+  "zuhiragana", "305A",
+  "zukatakana", "30BA",
+);
+
 (undef,undef,my $prog)=File::Spec->splitpath($0);
 
 unshift(@ARGV,split(' ',$ENV{GROPDF_OPTIONS})) if exists($ENV{GROPDF_OPTIONS});
@@ -2043,7 +6135,11 @@ sub FindChr
        }
        elsif (defined($thisfnt->{NAM}->{$ch}->[UNICODE]))
        {
-           return pack('U',hex($thisfnt->{NAM}->{$ch}->[UNICODE]))
+           return pack('U',hex($thisfnt->{NAM}->{$ch}->[UNICODE]));
+       }
+       elsif 
(exists($AGL_to_unicode{substr($thisfnt->{NAM}->{$ch}->[PSNAME],1)}))
+       {
+           return 
pack('U',hex($AGL_to_unicode{substr($thisfnt->{NAM}->{$ch}->[PSNAME],1)}));
        }
     }
     elsif ($ch=~m/^\w+$/)       # ligature not in font i.e. \(ff

I guess the above is where you decode the bookmark text/identifier.

Wouldn't it be better, once the \X/Savannah #64484 problem is solved, to
do this decoding in pdf.tmac and send Real McCoy to the postprocessor?

diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 78a93b27d..682955467 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -4939,6 +4939,45 @@ void chop_macro()
   skip_line();
 }
 
+const char * hex = "0123456789ABCDEF";
+
+void stringhex_request()
+{
+  symbol s = get_name(true /* required */);
+  if (s.is_null()) {
+    skip_line();
+    return;
+  }
+  request_or_macro *p = lookup_request(s);
+  macro *m = p->to_macro();
+  if (!m) {
+    error("cannot apply stringhex to a request ('%1')",
+         s.contents());
+    skip_line();
+    return;
+  }
+  string_iterator iter1(*m);
+  macro *mac = new macro;
+  int len = m->macro::length();
+  for (int l = 0; l < len; l++) {
+    int nc, c = iter1.get(0);
+    if (c == PUSH_GROFF_MODE
+       || c == PUSH_COMP_MODE
+       || c == POP_GROFFCOMP_MODE)
+      mac->append(c);
+    else if (c == EOF)
+      break;
+    else {
+      nc = (int)hex[(c >> 4) & 0x0f];
+      mac->append(nc);
+      nc = (int)hex[c & 0x0f];
+      mac->append(nc);
+    }
+  }
+  request_dictionary.define(s, mac);
+  tok.next();
+}
+
 enum case_xform_mode { STRING_UPCASE, STRING_DOWNCASE };

This appears to be modeled on the `stringup` and `stringdown` requests,
an early effort of mine (and themselves modeled on existing stuff from
James Clark and/or Werner).

I am a bit concerned now with what happens if you hand one of these
string-handling requests a diversion instead.

Not a short term issue, just a nagging worry.

 
 // Case-transform each byte of the string argument's contents.
@@ -8692,6 +8731,7 @@ void init_input_requests()
   init_request("soquiet", source_quietly);
   init_request("spreadwarn", spreadwarn_request);
   init_request("stringdown", stringdown_request);
+  init_request("stringhex", stringhex_request);
   init_request("stringup", stringup_request);
   init_request("substring", substring_request);
   init_request("sy", system_request);
diff --git a/tmac/pdf.tmac b/tmac/pdf.tmac
index 54175434f..e9d2b52cc 100644
--- a/tmac/pdf.tmac
+++ b/tmac/pdf.tmac
@@ -35,39 +35,9 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .
 .mso ps.tmac
 .
-.de pdf:SS
-.      fchar \\$1 \\S'16'\\$1\\S'0'
-..
-.pdf:SS \[+h]
-.pdf:SS \[ts]
-.pdf:SS \[*a]
-.pdf:SS \[*b]
-.pdf:SS \[*x]
-.pdf:SS \[*d]
-.pdf:SS \[*e]
-.pdf:SS \[*f]
-.pdf:SS \[*g]
-.pdf:SS \[*y]
-.pdf:SS \[*i]
-.pdf:SS \[+f]
-.pdf:SS \[*k]
-.pdf:SS \[*l]
-.pdf:SS \[*m]
-.pdf:SS \[*n]
-.pdf:SS \[*o]
-.pdf:SS \[*p]
-.pdf:SS \[*h]
-.pdf:SS \[*r]
-.pdf:SS \[*s]
-.pdf:SS \[*t]
-.pdf:SS \[*u]
-.pdf:SS \[+p]
-.pdf:SS \[*w]
-.pdf:SS \[*c]
-.pdf:SS \[*q]
-.pdf:SS \[*z]

This appears to be preparation for landing the PDF SS font and isn't
applicable to what Robin is trying to do.

 .char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'
 .nr pdf:bm.nl 1
+.\" .gcolor black     \" Until bug #64592 is addressed
 .de pdfmark
 . nop \!x X ps:exec [\\$* pdfmark
 ..

It's addressed.  https://savannah.gnu.org/bugs/?64592

@@ -213,10 +183,23 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .   \" then parse any specified options, to set a "tag", if required
 .   \"
 .      ds pdf:href-T
-.      while dpdf:href.opt\\$1 \{\
-.         pdf:href.opt\\$1 \\$@
-.         shift \\n[pdf:href.argc]
+.      ds pdf:hrefhex-T
+.      length pdf:l \\$1
+.      ds pdf:char1 \\$1
+.      substring pdf:char1 0 0
+.      if !'\\*[pdf:char1]'-' .nr pdf:l 99
+.      while (\\n[pdf:l]<4) \{\
+.         ie dpdf:href.opt\\$1 \{\
+.            pdf:href.opt\\$1 \\$@
+.            shift \\n[pdf:href.argc]
+.            length pdf:l \\$1
+.            if '\\$1'--' .break
+.            ds pdf:char1 \\$1
+.            substring pdf:char1 0 0
+.            if !'\\*[pdf:char1]'-' .nr pdf:l 99
 .         \}
+.         el .break
+.      \}
 .      rr pdf:href.argc
 .   \"
 .   \" If we found "--" to mark the end of the options, discard it

Can you explain the foregoing, please?

@@ -245,28 +228,35 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .   \" ( which we return in the string "PDFBOOKMARK.NAME" ),
 .   \"
 .      nr pdf:bm.nr +1
-.      ie '\\*[pdf:href-T]'' .ds PDFBOOKMARK.NAME pdf:bm\\n[pdf:bm.nr]
-.      el .ds PDFBOOKMARK.NAME \\*[pdf:href-T]
+.      ie '\\*[pdf:hrefhex-T]'' \{\
+.         ds PDFBOOKMARK.NAME pdf:bm\\n[pdf:bm.nr]
+.         ds PDFBOOKMARK.NAME.HEX \\*[PDFBOOKMARK.NAME]
+.         stringhex PDFBOOKMARK.NAME.HEX
+.      \}
+.      el \{\
+.         ds PDFBOOKMARK.NAME \\*[pdf:href-T]
+.         ds PDFBOOKMARK.NAME.HEX \\*[pdf:hrefhex-T]
+.      \}
 .      pdf:href.sety
-.         ds pdf:cleaned \\$*
-.         ev pdfcln
-.         tr \[em]-
-.         nf
-.         box pdf:clean
-.         nop \\$*
-.         fl
-.         box
-.         chop pdf:clean
-.         asciify pdf:clean
-.         length pdf:clean:len \\*[pdf:clean]
-.         ds pdf:cleaned \\*[pdf:clean]
-.         rm pdf:clean
-.         ev
-.         tr \[em]\[em]
-.      ds pdf:look(\\*[PDFBOOKMARK.NAME]) \\*[pdf:cleaned]
-.      if dPDF.EXPORT .tm .ds pdf:look(\\*[PDFBOOKMARK.NAME]) \\*[pdf:cleaned]
+.\" .         ds pdf:cleaned \\$*
+.\" .         ev pdfcln
+.\" .         tr \[em]-
+.\" .         nf
+.\" .         box pdf:clean
+.\" .         nop \\$*
+.\" .         fl
+.\" .         box
+.\" .         chop pdf:clean
+.\" .         asciify pdf:clean
+.\" .         length pdf:clean:len \\*[pdf:clean]
+.\" .         ds pdf:cleaned \\*[pdf:clean]
+.\" .         rm pdf:clean
+.\" .         ev
+.\" .         tr \[em]\[em]
+.      ds pdf:look(\\*[PDFBOOKMARK.NAME.HEX]) \\$*
+.      if dPDF.EXPORT .tm .ds pdf:look(\\*[PDFBOOKMARK.NAME.HEX]) \\$*
 .      pdfmark /Dest /\\*[PDFBOOKMARK.NAME] /View [\\*[PDFBOOKMARK.VIEW]] /DEST
-.      nop \!x X ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title 
(\\*[pdf:cleaned]) /Level \\n[pdf:bm.lev] /OUT pdfmark
+.      nop \!x X ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title (\\$*) /Level 
\\n[pdf:bm.lev] /OUT pdfmark
 .\".      pdfmark /Dest /\\*[PDFBOOKMARK.NAME] /Title "(\\*[pdf:cleaned])" 
/Level \\n[pdf:bm.lev] /OUT
 .      pdf:href.options.clear
 .      rr PDFPAGE.Y

This appears to still be work in progress given the amount of commented
code.  But it does seem to be the thing that encodes
potentially-Unicodeful bookmarks.

@@ -492,18 +482,27 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .ds pdf:href\\$1 \\$2
 .nr pdf:href.argc 2
 ..
+.de pdf:href.option-hex
+.\" ----------------------------------------------------------------------
+.\" ----------------------------------------------------------------------
+.ds pdf:hex \\$2
+.stringhex pdf:hex
+.ds pdf:href\\$1 \\$2
+.ds pdf:hrefhex\\$1 \\*[pdf:hex]
+.nr pdf:href.argc 2
+..
 .\"
 .\" Valid PDFHREF options are simply declared
 .\" by aliasing option handlers to "pdf:href.option",
 .\" or to "pdf:href.flag", as appropriate
 .\"
 .als pdf:href.opt-A pdf:href.option   \" affixed text
-.als pdf:href.opt-D pdf:href.option   \" destination name
+.als pdf:href.opt-D pdf:href.option-hex   \" destination name
 .als pdf:href.opt-E pdf:href.flag     \" echo link descriptor
 .als pdf:href.opt-F pdf:href.option   \" remote file specifier
-.als pdf:href.opt-N pdf:href.option   \" reference name
+.als pdf:href.opt-N pdf:href.option-hex   \" reference name
 .als pdf:href.opt-P pdf:href.option   \" prefixed text
-.als pdf:href.opt-T pdf:href.option   \" bookmark "tag"
+.als pdf:href.opt-T pdf:href.option-hex   \" bookmark "tag"
 .als pdf:href.opt-X pdf:href.flag     \" cross reference
 .\"
 .\" For references to another document file
@@ -533,6 +532,7 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .   \"
 .   while \\n(.$ \{\
 .      if dpdf:href-\\$1 .rm pdf:href-\\$1
+.      if dpdf:hrefhex-\\$1 .rm pdf:hrefhex-\\$1
 .      shift
 .      \}
 .   \}
@@ -560,6 +560,8 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\"
 .ds pdf:href-D
 .ds pdf:href-N
+.ds pdf:hrefhex-D
+.ds pdf:hrefhex-N
 .\"
 .\" Parse, interpret, and strip any specified options from the
 .\" argument list.  (Note that only options with a declared handler

We seem to be sprouting hex encodings all over the place.  I grow
increasingly uneasy with this, per point 1. above.  My intuition is that
if we're employing an obfuscating encoding to fit something into the
data structure we're using, we're using the wrong data structure.

@@ -567,10 +569,22 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\" options -- anything which is not recognised is assumed to start
 .\" the "descriptive text" component of the argument list).
 .\"
-.while dpdf:href.opt\\$1 \{\
-.   pdf:href.opt\\$1 \\$@
-.   shift \\n[pdf:href.argc]
+.length pdf:l \\$1
+.ds pdf:char1 \\$1
+.substring pdf:char1 0 0
+.if !'\\*[pdf:char1]'-' .nr pdf:l 99
+.while (\\n[pdf:l]<4) \{\
+.   ie dpdf:href.opt\\$1 \{\
+.      pdf:href.opt\\$1 \\$@
+.      shift \\n[pdf:href.argc]
+.      length pdf:l \\$1
+.      if '\\$1'--' .break
+.      ds pdf:char1 \\$1
+.      substring pdf:char1 0 0
+.      if !'\\*[pdf:char1]'-' .nr pdf:l 99
 .   \}
+.   el .break
+.\}
 .\"
 .\" If we found "--", to mark the end of the options,
 .\" then we should discard it.

This appears to be the code that is commented out above.

@@ -584,14 +598,24 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\" for the destination, then this marker will not be created.
 .\"
 .ds PDFBOOKMARK.NAME "\\*[pdf:href-N]\\*[pdf:href-D]
+.ds PDFBOOKMARK.NAME.HEX "\\*[pdf:hrefhex-N]\\*[pdf:hrefhex-D]
+.if '\\*[PDFBOOKMARK.NAME.HEX]'' \{\
+.  pdf:href.option-hex -D \\$1
+.  if '\\*[pdf:hrefhex-D]'' \{\
+.    pdf:error pdfhref has no destination
+.    nr pdf:href.ok 0
+.  \}
+.  ds PDFBOOKMARK.NAME \\*[pdf:href-D]
+.  ds PDFBOOKMARK.NAME.HEX \\*[pdf:hrefhex-D]
+.\}
 .pdf*href.set \\*[PDFBOOKMARK.NAME] \\$1
-.ds pdf:look(\\*[PDFBOOKMARK.NAME]) \\$*
-.if dPDF.EXPORT .tm .ds pdf:look(\\*[PDFBOOKMARK.NAME]) \\$*
+.ds pdf:look(\\*[PDFBOOKMARK.NAME.HEX]) \\$*
+.if dPDF.EXPORT .tm .ds pdf:look(\\*[PDFBOOKMARK.NAME.HEX]) \\$*
 .\"
 .\"
 .\" Irrespective of whether this marker is created, or not,
 .\" the descriptive text will be copied to the groff output stream,
-.\" provided the "-E" option was specified
+.\" provided the "-E" option was sp0ecified
 .\"
 .if \\n[pdf:href-E] \&\\$*
 ..

Typo in comment.

@@ -650,10 +674,22 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\" options -- anything which is not recognised is assumed to start
 .\" the "link text" component of the argument list).
 .\"
-.while dpdf:href.opt\\$1 \{\
-.   pdf:href.opt\\$1 \\$@
-.   shift \\n[pdf:href.argc]
+.length pdf:l \\$1
+.ds pdf:char1 \\$1
+.substring pdf:char1 0 0
+.if !'\\*[pdf:char1]'-' .nr pdf:l 99
+.while (\\n[pdf:l]<4) \{\
+.   ie dpdf:href.opt\\$1 \{\
+.      pdf:href.opt\\$1 \\$@
+.      shift \\n[pdf:href.argc]
+.      length pdf:l \\$1
+.      if '\\.$1'--' .break
+.      ds pdf:char1 \\$1
+.      substring pdf:char1 0 0
+.      if !'\\*[pdf:char1]'-' .nr pdf:l 99
 .   \}
+.   el .break
+.\}
 .\"
 .\" If we found "--", to mark the end of the options, then we should
 .\" discard it.

This appears to be the code that is commented out above, again.

Maybe it should pulled into a separate macro?

@@ -666,8 +702,8 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\" can't identify the destination, then set "pdf:href.ok" to zero,
 .\" so this link will not be created.
 .\"
-.if !dpdf:href-D .pdf:href.option -D \\$1
-.if '\\*[pdf:href-D]'' \{\
+.if !dpdf:href-D .pdf:href.option-hex -D \\$1
+.if '\\*[pdf:hrefhex-D]'' \{\
 .   pdf:error pdfhref has no destination
 .   nr pdf:href.ok 0
 .   \}
@@ -700,7 +736,7 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .      ds PDFHREF.DESC \\\\$*
 .      \}
 .   el \{\
-.      ie dpdf:look(\\*[pdf:href-D]) .ds PDFHREF.DESC 
\\*[pdf:look(\\*[pdf:href-D])]
+.      ie dpdf:look(\\*[pdf:hrefhex-D]) .ds PDFHREF.DESC 
\\*[pdf:look(\\*[pdf:hrefhex-D])]
 .      el .ds PDFHREF.DESC Unknown
 .      \}
 .   \" Apply border and colour specifications to the PDFMARK string

I don't understand the pdfhref API very well, but it does seem to be
large, and not doing a lot to help us here.

Thank you in advance for considering my comments.

Regards,
Branden

[1] https://savannah.gnu.org/bugs/?64484

signature.asc
Description: PGP signature