[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #8, bug #64202 (group groff):

[comment #7 comment #7:]
> I'm rejecting this.
Fair enough; that is your prerogative.  It doesn't make it any less of a bug;
it just makes it a bug which you have decided you will not fix!  In any case,
I have a work around.
> If a PDFMark tag indexing system constructs _groff_ identifiers
> from arbitrary input strings, that system is responsible for
> ensuring that the constructed identifiers are syntactically valid.
That is *not* the issue here.  The issue is that your unnecessary '\%' prefix
infiltrates the text of the pdfmark '/Link' annotation, which defines the
destination of the resultant PDF hyperlink; there is no attempt to construct a
_groff_ identifier from this text.  My work around simply iterates over the
initial part of the string, discarding the first character while it is '\%',
and keeping the remainder of the string, as soon as its first character
becomes anything other than '\%'.

In fact, I am not aware of any code, within _pdfmark.tmac_, which attempts to
construct a _groff_ identifier from arbitrary input text; if _you_ know of
any, please do bring it to my attention.
> The _groff_ language has, for decades, supported the `\A` escape
> sequence to assist with this.
I am aware of this.  Indeed, just last week, I *did* stumble on some code
which *does* attempt to *match* arbitrary input text to (a part of) a
*pre-existing* _groff_ identifier, using _.if d prefix.\\$1_ as the sole test.
 In the particular context, the effect was completely innocuous, aside from
raising an unexpected warning.  The solution, to avoid the warning, was to
test _.if \A'\\$1'_ *first*, and to perform the _.if d ..._ test only if that
returns _true_.
> Unfortunately, it has also lacked a string iterator that would make
> it easier to _do_ something about arbitrary input strings one's tag
> indexing system encounters.  (Apart from aborting the formatter or
> risking incorrect lookups on tag values, that is.)  Providing such
> a facility is contemplated as a future _groff_ language direction
> in bug #62264.
I agree that string iteration could be made more convenient, but it *is*
already possible ... I do it, in my _sanitize.tmac_, to filter out special
codes, which do not render appropriately in PDF outline text.
> I decided to solve this problem in "pdf.tmac" by not constructing
> _groff_ identifiers from arbitrary input strings, instead using
> another string, indexed by the bookmark's sequence number.  This
> does come at the price of turning tag lookup time from constant in
> the number of already-recorded tags to linear.
As I've pointed out above, identifier construction is *not* relevant to this
issue, so what you have done in _pdf.tmac_ has no bearing on what I have had
to do, to work around your bug.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64202>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/