Follow-up Comment #12, bug #67418 (group groff): At 2026-06-19T11:21:32-0400, Deri James wrote: > Follow-up Comment #11: > > It is possible to make hdtbl compatible with other macro packages (ms > and mm).
Yes; I think there are multiple ways.
> The main issue is the joint use of TH as a macro, it can occur between
> TS/TE (tbl) or between TBL/ETB (hdtbl) this means that TH can be
> aliased to the correct "version" of TH in the TS or TBL macros.
That's true, but it doesn't solve the collision with man(7), which would
be nice to resolve in theory. Not that I advocate the use of extension
macro packages for composition of portable man pages. I suspect Ingo
would share my view.
> Caveats
> =====
>
> In ms the macro TR results in "not implemented" in order to trap AT&T
> documents which used it. I believe this macro was used in setting up
> the cover page so only occurs once in the document,
Agreed. I don't think it has a defined meaning in AT&T beyond the
initial set of macros that configure the cover page.
> so long as it occurs before the first TBL it will result in "not
> implemented", otherwise it will result in an error.
>
> The order of -ms and -mhdtbl on the command line should not matter.
Here I think I disagree. An unwritten rule--which we might consider
making more "official"--in *roff document composition appears to be that
use of auxiliary packages should come _after_ a full-service package is
selected.
This rule is consistent with the one we already document about loading
localization macro packages _after_ full-service packages. For example:
$ groff -ms -mfr bienvenue.ms # recommended
$ groff -mfr -ms bienvenue.ms # DISCOURAGED
An important point is that subsequent loading of auxiliary packages need
not be done on the command line; `mso` requests in the document are also
possible, and might be preferable for flexibility/portability reasons
since they can be wrapped with conditional requests like `if` and `ie`.
> TH in man is used only at the top of the document so will not affect
> it, BUT in continuous mode with multiple man pages this is not true,
> so hdtbl can only be used with single man pages.
Right. That's a frustrating limitation from my perspective, as I spent
considerable effort making batch rendering of man pages work reasonably
well.
> I don't know if man support multi page table headings i.e. TS H/TH/TE,
> I suspect not.
It does not. I don't think mdoc(7) does either.
> Branden, is this a better solution to the regression described in this
> bug, i.e. to allow use of hdtbl in combination with other packages,
> rather than making it impossible to use it? I will assume you are
> happy (and busy with 1.25.0) if I here nothing and I can commit the
> patch.
I think a better solution is to (a) amplify and reinforce the above rule
about ordering of macro package loads, and (b) promulgate a new rule
that auxiliary macro packages should employ name spacing.
Thus, I propose that "hdbtl" rename its interface macros to start with
`hdtbl*` or similar. A document author can, at their option, set up
aliases to abbreviate usage if they like, and where doing so doesn't
create grief with the full-service package they're using.
I had in mind to withdraw "www.tmac" someday, but maybe it can live if
we apply the aforementioned name spacing to it. After the _groff_ 1.25
release, I want to adapt your `PDFFEAT` work on ms(7) to me(7) and
mm(7), and I suspect that there will be opportunities to factor out some
common techniques. The existing "www.tmac" file might be a good
destination for such sharable components.
> You are not allowed to embed a heidelberg table within a tbl table or
> vice-versa.
Actually enforcing this would likely involve adding conditionals[1] to
hdtbl's interface macros to check for the existence of a register used
by GNU tbl. Likely an existing one could be used as a sentinel, or we
could add one to GNU tbl of Boolean sense.
Regards,
Branden
[1] or define an internal "checker" macro that the interface macros
call
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67418>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
