[Groff] Re: Fw: pdfmark question

[Keith Marshall]

On Sunday 23 September 2007 21:46, Nick Stoughton wrote:
> > Can't you cut the paragraph in which the fault appears, from your
> > complete source, and format it stand-alone with the same page
> > layout settings?  Does that not exhibit the same problem?  If it
> > does, could you please send it to me, as a test case?
>
> I think I have figured it out ...
>
> The attached diff does the following:
>
> Makes  pdf*href.mark.end move left BEFORE putting the "|" symbol out
> ... preventing the line break that caused problems.

Yes, my first thought was to do something similar.

> As a result, the x coordinates emitted by the \O2 are too far to the
> right, by the width of the "|". So the pdf*href-Z macro has to add
> this width to the x-displacement.

In that case, would the `opmaxx' value, output by \O2, not be the 
value required, rather than the `opminx' value used at present?  Of 
course, using that would mean a change in pdfroff, to copy the other
value to document map.

> It certainly fixes my problem ... hope this is an acceptable/useful
> patch in general.

It looks reasonable, but I think I've found a simpler solution.  
First, I've created a test case, which I think reproduces your 
problem:

.\"--------8<--------------------------------------------------
.\" vim: ft=groff
.
.\" A test case to explore pdfhref hot-spot location fault,
.\" reported by Nick Stoughton, were the location machinery
.\" misplaces the hot-spot as a result of word wrapping
.\" caused only by the ultimately discarded end marker.
.
.\" Format this test case using:--
.
.\"   pdfroff -mspdf --no-toc fido.ms > fido.pdf
.
.\" Define some text, and set line length so it will fit
.\" exactly, with no space left for hot-spot markers.
.
.ds text "the quick brown fox jumps over the lazy\"
.nr LL \w'\*[text] dog'u
.
.\" Make the hot-spot locations, and extents visible, by
.\" outlining them.
.
.ds PDFHREF.BORDER 0 0 1
.
.SH
Exact Fitting Text,
.br
With Reference at End
.LP
.\" This will fit the line length exactly, *after* the
.\" hot-spot markers are discarded -- in the preliminary
.\" passes, the markers will cause the word defining the
.\" hot-spot to move to the next line.
.
\*[text]
.pdfhref L dog
.sp 10c
.
.\" Here's some nonsense, for the preceding link to
.\" refer to.
.
.SH
.pdfhref M dog
A Dog Called Fido
.LP
ToDo: Write Fido's biography here.
.LP
\*[text] dog
\*[text] dog
\*[text] dog
\*[text] dog
.
.\" EOF
.\"--------8<--------------------------------------------------

Format that with the current CVS version of pdfmark.tmac, and you 
should see an outlined hot-spot at the start of a blank line, 
immediately following a line ending in the word `dog'; it is that 
word which *should* define the hot-spot.  I believe this is the 
same problem as you described.

Now, this simple patch fixes it for me:

Index: contrib/pdfmark/pdfmark.tmac
===================================================================
RCS file: /cvsroot/groff/groff/contrib/pdfmark/pdfmark.tmac,v
retrieving revision 1.8
diff -u -r1.8 pdfmark.tmac
--- contrib/pdfmark/pdfmark.tmac   11 Apr 2007 22:45:11 -0000   1.8
+++ contrib/pdfmark/pdfmark.tmac   25 Sep 2007 23:17:04 -0000
@@ -1855,7 +1855,7 @@
 .de pdf*href.mark.end
 .\" ----------------------------------------------------------------------
 .\" ----------------------------------------------------------------------
-\O1|\h'-\w"|"u'\O2\c
+\O1\Z'|'\O2\c
 ..
 .\" Macro "pdf*href-I" is used for one time initialisation of special
 .\" "pdfhref" features; (currently, only the above page trap hook is

Please let me know if this also works for you; if `yes', then I'll
commit it, but I'll keep your patch, just in case I've misunderstood 
the problem, or the simpler solution doesn't suffice.

Regards,
Keith.