[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #5, bug #63827 (project groff):

[comment #3 comment #3:]
> [comment #2 comment #2:]
> > ...
> > More importantly, my simple implementation relies on the '!d'
> > conditional, which I suspect may be groff-specific, (is it?),
> 
> Yes.  Subsection "Conditional expressions" of groff_diff(7) covers
> it, and the other extensions.
Thanks, but there is no such subsection, in the version of groff_diff(7) on my
Manjaro (Arch Linux) system.  The information is there, but not so easily
found.  In any event, I had been perusing 'info groff', which -- again in the
installed version -- does not make it clear that '.if d...' is a groff
extension, at the point where the conditional operators are described.
> ...
> > if we are concerned about non-groff compatibility,
> 
> The test is not so much for implementation of groff extensions as
> the likelihood of the `MR` macro being already defined by that
> implementation.  If one exists, I don't want to clobber it because
> it can do much more than just typeset the arguments.  It can embed
> hyperlinks on supporting output devices.
Provided the implementation which does exist will DTRT, w.r.t. the
expectations from using the groff >= 1.23 implementation, sure.  But if you
don't know for sure that any existing implementation mimics groff >= 1.23
behaviour, all bets are off; you surely *do* want to clobber it. 
> groff's man pages all have that logic at the top and bottom that
> takes the body of the page out of compatibility mode,
Sure, but what if that compatibility save, disable, then restore hack doesn't
work?  If the page source is passed through a formatter which doesn't support
the 'do' and 'cp' requests, or otherwise support groff extended syntax, then
all kinds of output garbage may ensue.
> and the pages generally use groff extensions like special characters
> that aren't documented in CSTR #54, often using the \[foo] syntax
> that also wasn't supported by AT&T troff.
In which case, attempting to retain even a modicum of support for legacy
formatting engines is likely a forlorn venture, so why bother?
> > can we safely use long register names, such as your 'do-fallback'?
> 
> I think we can, because Heirloom, mandoc(1), and older groffs
> support them.
I'm inclined to disagree, only to the extent that any legacy formatter may be
confused by them, but maybe I'm just being excessively pedantic.
> The idea is to get something that works on Heirloom Doctools troff,
> mandoc, and older versions of groff.  This doesn't work perfectly in
> general, but for the MR feature specifically, it does.
Fair enough, provided we're happy to abandon any hope of legacy formatter
support otherwise.


    _______________________________________________________

Reply to this item at:

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

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