Re: groff 1.23.0.rc2 status report (was: [BUG] gropdf, tbl: Completely broken table)

[Deri]

On Monday, 19 December 2022 05:32:45 GMT G. Branden Robinson wrote:
> Number three:
> 
> bug #62933: [man] produce hyperlinks in PDF output
> https://savannah.gnu.org/bugs/index.php?62933
> 
> We've got man page cross-reference hyperlinks but, weirdly, not regular
> URL support in groff_man(7).  To my dismay this doesn't appear to be
> trivial.  Whoever came up with the "pdfhref" macro had Unix
> command-line-itis, and constructed an interface that looked like that
> instead of something you might use in a *roff document. 

Hi Branden,

To be fair, he had little choice since the api was designed by adobe:-

https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/
acrobatsdk_pdfmark.pdf

> The problem is
> that it expects the URL and, particularly, the link text to be macro
> arguments.  This is a violent impedance mismatch with the way groff
> man(7)'s email and web macros were set up to work; they format the link
> text in a diversion.  Diversions and strings are not the same thing.
> (Try putting diversion contents into a device control command and you
> will rapidly be deafened by the screams of a thousand damned "can't
> output node in transparent throughput" souls.)  

The .URL, .MTO and .FTO macros in www.tmac should be easy to convert to using 
.pdfhref, the difficult one is the .UR/.UE pair from an.tmac you are talking 
about.

In order to solve this to get all man pages as fully linked pdfs - I cheated! 
I used a sort of pre-gropdf which changed the mail and email links to pdfhref 
calls. So I don't think I can help much with this. However, this is the code I 
use to "clean" a string, may be helpful:-

.         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]

There may be much better ways of doing it!

> So to solve this I have
> to learn crazy stuff about PDFmark hotspots and how their boundaries are
> computed, and then the thought of what happens when the link text
> crosses a trap boundary (like a page break) causes the blood to drain
> from my face.  

Don't worry, the gropdf man page says:-

If you are using page traps to produce headings, footings, etc., you need to 
use these in case a ‘hotspot’ crosses a page boundary, otherwise any text 
output by the heading or footing macro will be marked as part of the ‘hot 
spot’. To stop this happening just place ‘.pdfmarksuspend’ and 
‘.pdfmarkrestart’ at the start and end of the page trap macro, respectively. 
(These are just convenience macros which emit the \X code. These macros must 
only be used within page traps.)

If you look at om.tmac you will see these used in the FOOTER macro. I'm not 
sure how -mpdfmark handles it since these are gropdf extensions.

Cheers

Deri

> At some point I may have to tell Regis I need to phone a
> friend,[3] and I'll crawl to Deri the PDF wizard to knock some clues
> into my head.
> 
> Then, though the bug doesn't say this, I have to do it all over again
> for mdoc(7), because that doesn't have support for this, either.  On the
> bright side, I have a much better grasp of mdoc(7)'s internals than I
> used to, and pretty much everything to do with page location traps is
> the same now anyway, thanks to my incessant meddling^W^W^Wthe problems I
> had to solve to get batch-rendering working.
>