Follow-up Comment #14, bug #67418 (group groff): On Saturday, 20 June 2026 06:56:16 BST you wrote: > 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.
I think we can ignore man. Do we really want man authors to start using
heidelberg tables, I don't think it would be a popular idea in some quarters.
So I propose we don't add support for man.
>> 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.
Good.
>> 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.
I support you in this. My comment was in response to Morten's comment #3 about
changed behaviour depending on order.
[...]
>
>> 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.
See above, I don't think we should support hdtbl with man.
> 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.
(a) Agreed.
(b) This is what my patch does, allows hdtbl to be used with ms and me with no
interface conflict.
> 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'm afraid that horse has bolted, there may be 1000s of ms/hdtbl documents
(which don't use tbl) which will no longer work after commit 73262611.
> 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.
I've never looked at www.tmac, given its age I assumed it was an adjunct to -
Thtml.
>> 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.
Documenting that it is not supported would be an alternative.
> 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
