Follow-up Comment #9, bug #67602 (group groff): At 2025-10-21T13:31:26-0400, Deri James wrote: > Update of bug #67602 (group groff): > > Severity: 3 - Normal => 5 - Blocker > Status: Fixed => Confirmed > > _______________________________________________________ > > Follow-up Comment #8: > > Unfortunately, the committed fix does not work and breaks pdf.tmac. > > The pdf:lookup macro should do two things:- > > Set pdf:lookup-result if a given destination name is found. > Set pdf:lookup-value to the text used when the destination named, i.e. > > .pdfbookmark -T destination-name -- 1 text > .pdfbookmark -T Intro -- 1 Introduction to Programming > > So:- > > .pdf:lookup Intro > > Should return this (if "Intro" exists as a destination):- > > pdf:lookup-result = non-empty (actually returns "Intro") > pdf:lookup-value = "Introduction to Programming" > > The purported fix below does no lookup at all, it simply sets > pdf:lookup-result to \\*1!!! > > So whatever you "lookup" (so long as it is not the empty string) will > return as "found”, and there is no way of retrieving the text > associated with the destination. > > Currently git is "red" because neither Groff-man-pages.pdf
I checked this document specifically and could not find problems--I clicked on multiple internal bookmarks at the extremes of the document and they navigated (in Okular) without trouble. And the tree _isn't_ red, it's green--because we don't have a test script that checks PDF bookmarking for correctness. Something that fragile should probably have a unit test for it. > nor mom-pdf.pdf are building correctly. I didn't check mom-pdf.pdf, but should have. I'll see if I can locate problems with it. > In our man pages book (and Alex's book) a .MR to a man page outside > the book should result in a man:/ url but because the pseudo lookup > always returns true (non-empty) this is not happening. I'll check that too. An actual test script would be helpful here, but since I was focused on the performance issue, I neglected to explore possibilities for programmatically constructing a document large enough to reliably expose the performance regression. (What occurred to me was to populate a document with dictionary words, where each was bookmarked and had at least one hyperlink to it elsewhere in the document.) > For the mom-pdf.pdf you will notice some (see: "") rather than the > appropriate text appearing, because pdf:lookup-value is not being set > to the text associated with the destination. Okay. I took a few days away from groff development and apparently lost my place. The solution seemed shockingly easy, so I'm not surprised that it was a case of fools' gold. > I did mention in comment #5 that you should retain the current api, so > I don't understand why pdf:lookup-value has "vanished". _At the time_, it didn't seem necessary to retain while solving the problem. Happy to restore that string name if it is. > I understand your desire to reduce the large document production time > down from 40 minutes to 30 seconds, I wonder who put that notion in my head. ;-) > which is what it took before you made changes to pdf.tmac whilst I was > on a sabbatical. True, and you've raised this point before--and as I noted then, you similarly swooped in after a period of inactivity with some changes while I was about four days into bereavement leave, so to speak. https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=98b0c1db47659cd203b7eaba8382e1e7a36d0288 https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=2387949ffc11b753dd91480dcb85be6c22819790 https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=cbe5a7802df5ff3a9f84a42e277cf3925a1eb303 Either that conduct is a problem for both of us, or it isn't. If it isn't, it isn't worth harping on when I make a mistake. > I will remind you that the code in dj-gropdf-ng does do a proper > lookup solution in about 30 seconds, but you have not brought it over > to master. I can certainly have a look. I wanted to see if I could solve the problem myself, especially since the "aliasing trick" seemed promising. My advice is to spend less time expressing offense over regressions. Writing scripts to catch them is a better use of everyone's time. We have over 280 examples in the tree already of how to do that. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67602> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
