[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63827] withdraw contrib/pdfmark

From: Keith Marshall
Subject: [bug #63827] withdraw contrib/pdfmark
Date: Fri, 24 Feb 2023 10:08:46 -0500 (EST)

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:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]