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/
