Follow-up Comment #10, bug #64202 (group groff): [comment #9 comment #9:] > [comment #1 comment #1:] > > 3. The reason for that is that man page content is partially > > dynamic. The redundancy you're observing is the result of the > > "@g@" character sequence being replaced by the ./configure-d > > command prefix in use by the build. By default, and in many > > build scenarios (of those I've seen personally, all except for > > Solaris), this prefix is empty. > > This was and remains true. I think we had already agreed that the issue arose from expansion of the '@g@' configuration macro, the intent of which is to support addition of (normally) 'g' as a program name prefix. That many systems do not specify such a prefix is certainly true, but is not germane to this issue anyway -- the addition of 'g', as prefix, would not cause any problem. However, that the expansion of '@g@' is similarly empty, in the case of groff's generated man pages, is apparently *not* true. In the case of _groff_man.7_, which I cited as an example merely because that's what drew my attention to this issue, '@g@' appears to expand to '\%', and when that infiltrates a PDF hypertext reference, via a PDF-centric overridden 'MR' macro, it becomes a problem. I have little doubt that _groff_man.7_ is not alone, in exhibiting this affliction. > > 4. @g@ is expanded in several contexts, not just the first > > argument of `MR`. Wherever it occurs, it is part of a literal to > > which we do not want automatic hyphenation to apply. > > This was and remains true. I have no doubt that this is the case. However, there are many similar literals, which are *not* prefixed by '@g@' but should also not be hyphenated. You have conflated two unrelated concepts into the expansion of a single configuration macro, which does not have sufficient degrees of freedom to separate the two concepts. At best, that is a gross abuse of the '@g@' macro, which I contend is a bug. > A built _groff_ 1.23.0 tree does not produce any instances of > `\%\%` in any of its man pages, as a _grep_ will readily confirm. Which is *not* the issue, and I never said that it was. That there is just one '\%' at the start of *some* 'MR' topic references, (and it seems to be just those which are prefixed by '@g@'), *is* the problem, because that infiltrates, and corrupts PDF hypertext references, which are compiled from the 'MR' arguments. > Your ticket title appears to have been deceptive. Possibly. It is, perhaps, misleading that I cited _groff_man.7_ as *the* problem page. It is *a* problem page; I have no doubt that there are others. > I should have demanded evidence from you at the time; I will have > settle for doing so now. I based my original testing on:
$ ../groff-build/config.status --version GNU roff config.status 1.23.0.rc4.59-51a03-dirty configured by ../groff-tmp/configure, generated by GNU Autoconf 2.71, with options "" In my local build from that _groff-tmp_ git checkout, I see: $ grep '^\. *MR' ../groff-build/tmac/groff_man.7 .MR groff_man_style 7 , .MR man 1 .MR intro 1 .MR groff_man_style 7 .MR man 7 .MR grotty 1 ). .MR groff_man_style 7 . .MR \%tbl 1 .MR groff 7 .MR groff 7 . .MR groff 7 . .MR groff 7 ). .MR \%tbl 1 , .MR \%eqn 1 , .MR \%refer 1 .MR man 1 .MR groff_mdoc 7 .MR groff_man_style 7 , .MR groff 7 , .MR groff_char 7 , .MR man 7 Note that of all 'MR' references, only four exhibit the redundant '\%' prefix, (redundant because, presumably, 'MR' would be expected to suppress hyphenation of its output, in any case, even without an explicit '\%' prefix), and inconsistent for the fairly obvious reason: (most 'MR' references omit the '\%' prefix, but just a few have it). Furthermore, I see: $ grep '^\. *MR *@g@' ../groff-build/tmac/groff_man.7.man .MR @g@tbl @MAN1EXT@ .MR @g@tbl @MAN1EXT@ , .MR @g@eqn @MAN1EXT@ , .MR @g@refer @MAN1EXT@ This would appear to confirm that, where this redundant '\%' prefix appears, it is the result of expansion of '@g@'. > In the absence of such evidence, I regard your claim of bugginess > as unfounded. Changing status to "Invalid". Frankly, I could not care less what you choose to do, henceforth. I say this is a bug; you may disagree, in which case we must agree to disagree. I now have a satisfactory work around for this bug, and I have no further interest in contributing to _groff_, or in pursuing any further local builds. I shall continue to maintain _pdfroff_, _pdfmark.tmac_, and associated documentation independently; this has already diverged significantly from its state, when I ceased to maintain it as a part of _groff_. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64202> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/