bug-groff
[Top][All Lists]
Advanced

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

[bug #63827] withdraw contrib/pdfmark


From: G. Branden Robinson
Subject: [bug #63827] withdraw contrib/pdfmark
Date: Thu, 23 Feb 2023 19:28:48 -0500 (EST)

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

[comment #2 comment #2:]
> Granted, that doesn't address the possibility that MR might be invoked with
fewer than two arguments -- because pdfroff.1.man never calls it with fewer --
but that's a trivial adjustment, for the more general case.

Right.

> 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.

> in which case, I need to address that.  However, on a related note, 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.

groff's man pages all have that logic at the top and bottom that takes the
body of the page out of compatibility mode, 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.

groff_man*(7) is a _little_ more conservative--though I have repeatedly
questioned the worth of treating it any differently.

> 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.

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.

For what it's worth, the pdfroff(1) man page in groff 1.22.3 (before I showed
up) uses the following "groffisms".

* groff-style special character escape sequences \[co]
* groff-style string interpolation escape sequences \*[lq], \*[rq]
* non-hyphenated break point escape sequence \:
* groff man(7) extension macros: UR, UE, MT, ME, SY, YS
* "all arguments" interpolation escape sequence \*
* special character identifiers: oq, cq, aq

It also uses the following features which Ingo Schwarze recommends against and
may not work, or not work fully, in mandoc(1).

* macro definition: de
* hyphenation exception word request: hw
* alteration of hyphenation mode: hy 

This old pdfroff(1) also sets the hyphenation mode to 1 at the end of the `NH`
definition (implicitly
<https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?h=1.22.3.real#n1651>).
 Unfortunately, there is no portable way to access or store the current
hyphenation mode.  Further the mode numbers are not portable across
implementations; not because they have different meanings (though groff has
extended values not supported by AT&T) but because the hyphenation patterns
themselves have different expectations about where the possible hyphenation
points in words are.  (The AT&T implementation assumed invariants that hold
only for languages like English.)

It also uses a special character identifier that is not defined in any
implementation I know of, "ok".  (Possibly a typo.)

I decided when I started working on groff's man pages, as I learned more about
the capabilities of "classic" troff, that it wasn't worth trying to achieve
perfect portability to Version 7 Unix troff.  Too much would have to be
sacrificed.

Other man page authors and maintainers can of course have different goals.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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