[bug #66165] commit dcae60b0fb1ad3fa3314fdfdbecb973961a40410 has wrong assumption

[G. Branden Robinson]

Follow-up Comment #3, bug #66165 (group groff):

Okay, I found the problem.  I instrumented line 292 of "pdf.tmac" and it
showed right up.


$ ./build/test-groff -UZ -T pdf ./ATTIC/woolly-faced-neanderthal.groff | grep
'^x X'
x X ps:exec [/Dest /pdf:bm1 /View [/FitH 5001 u] /DEST pdfmark
x X ps:exec [/Dest /pdf:bm1 /Title (Introduction) /Level 1 /OUT CRO-MAGNON
FREAKOUT pdfmark
x X ps:exec [/Dest /pdf:bm2 /View [/FitH -31000 u] /DEST pdfmark
x X ps:exec [/Dest /pdf:bm2 /Title (My day with a woolly-faced neanderthal)
/Level 1 /OUT CRO-MAGNON FREAKOUT pdfmark
x X pdf: pdfpic ATTIC/woolly\[u2010]faced\[u2010]neanderthal.pdf \[u2010]L
468000z 605880z


And what is that line, once my cro-mag nonsense is removed?


$ sed -n '292p' tmac/pdf.tmac 
.      nop \!x X ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title (\\*[pdf:title])
/Level \\n[pdf:bm.lev] /OUT pdfmark


Observe the gymnastic achievement of a device extension command via *neither*
the `\X` escape sequence *nor* the `device` request, but raw grout stuffed
into a "transparent throughput" escape sequence!

Why such indirection? 
[https://git.savannah.gnu.org/cgit/groff.git/commit/?id=4536678ce5713907304ad1695e907f6888c44aa3
It looks for all the world like a quick hack way back in 2012 to get around
problems with the "pdfmark" package, or maybe with _troff_ itself.]


-.      pdfmark /Dest /\\*[PDFBOOKMARK.NAME] /Title (\\*[pdf:cleaned]) /Level
\\n[pdf:bm.lev] /OUT
+.      nop \!x X ps:exec [/Dest /\\*[PDFBOOKMARK.NAME] /Title
(\\*[pdf:cleaned]) /Level \\n[pdf:bm.lev] /OUT pdfmark
+.\".      pdfmark /Dest /\\*[PDFBOOKMARK.NAME] /Title "(\\*[pdf:cleaned])"
/Level \\n[pdf:bm.lev] /OUT


The retention of that pdfmark macro call as a commented line is suggestive.

I'm guessing that either the "pdfmark" macro was trying to do too much (a safe
bet in my experience), and/or that using `device` or `\X` directly had
undesirable side effects.  "Fortunately", GNU _troff_ was inconsistent and the
nowhere-documented differences between these disparate means of stuffing bytes
into grout was usable to one's advantage here.  And thus a quick hack settled
in for a 12-year residency without the problems provoking it getting
addressed.

This hydra-headed beast of inconsistency is what I'm trying to kill in bug
#63074.


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature