Re: Help needed with pdfroff and suppression nodes

[Keith Marshall]

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.