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.
