Hi Branden, On 29/07/2021 10:45, G. Branden Robinson wrote: > I just pushed the following commit--I've got a problem I'm having a > devil of a time figuring it out. > > As noted below, I caused a regression a couple of days ago, but one that > was hard to see since it didn't break the build. The table of contents > was not getting relocated in pdfmark.pdf. The only evidence of this (if > you didn't so something crazy like view the file) was a stray line in > the build: > > pdfroff-option:set toc_relocation=enabled > > This is emitted by spdf.tmac, and normally, apparently, something eats > it.
Yes, it is emitted (on stderr) when the document source invokes the TC macro, to flush out the TOC diversion to the stdout stream, at the end of input, (as is conventional in ms document processing). pdfroff has captured that stderr stream, during its pdfmark reference collection phase, and subsequently interprets it, by evaluating: eval `$SED -n '/^ *pdfroff-option:set */s///p' $WRKFILE` which becomes equivalent to the shell variable assignment: toc_relocation=enabled This then prevents pdfroff from automatically activating the effect of its --no-toc-relocation option. > So if you see it, it indicates the TOC relocation failed--at least > it did in this case. I think your conclusion is incorrect here — at least to the extent that the appearance of this stderr output isn't the *cause* of the problem, but is rather a symptom of a more serious underlying problem, which you have introduced; its appearance suggests that pdfmark is no longer being passed the reference data, which should have been captured during the aforementioned collection phase, so never sees the condition it expects for suppression of reference data output to stderr. > Now that the error condition is caught and troff doesn't exit > unexpectedly, the regression is fixed. Are you sure about that? Why should troff be exiting unexpectedly anyway? As Tadziu has already noted, pdfmark uses \O escapes to mark anchor points; specifically, it brackets each pdfhref link with: \O1\Z'|'\O2\c at both the start and the end of the link region; these result in grohtml-info:page references being written to stderr, (specifically emitted by the \O2 escape), from whence pdfroff converts them to: .pdfhref Z ... references, which are then inserted into the input stream, for all subsequent processing cycles. If those references aren't produced, in an *exactly* matching number to the number of \O2 markers, the pdfroff never knows when to stop emitting reference data on stderr, and its behaviour *will* become undefined. > (Should pdfroff be checking groff's exit status?) I don't know what it would do with it — apart from possibly just aborting early. > But the wheels turning here mystify me. What is causing the > `image_filename` (formerly `last_image_filename`) to go uninitialized, > why only in very specific circumstances? There is no image_filename involved; nor is there any need for one. The \O1 and \O2 escapes *must* work (as before), *regardless* of whether an image_filename is available, or not; (in the pdfmark context, it is unlikely that there will ever be one). I guess you need to rework (or revert) your change, to ensure that \O escapes continue to work, with or without an image_filename. Why do you suspect that the lack of an image_filename would cause a SIGSEGV abort? I have never seen any evidence of that occurring, with pdfroff. -- Regards, Keith.
