[Top][All Lists]

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

Re: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered

From: G. Branden Robinson
Subject: Re: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered
Date: Mon, 13 Feb 2023 23:10:54 -0600

Hi Brian,

At 2023-02-13T16:41:42-0700, Brian Inglis wrote:
> On 2023-02-12 18:48, G. Branden Robinson wrote:
> > At 2023-02-11T18:17:49-0700, Brian Inglis wrote:

> Thanks very much Branden, These comments really help.  I have hacked
> around between the original and your suggested approach to find
> something that will work for now.

Great!  I'm glad you've found a local optimum that isn't too painful. :)

> I will highlight tables need to be less than a page.

I'm curious to know how people in the ultimate source format (you said
something about comments embedded in source code) are supposed to judge
this.  That said, the list of format conversions supported by newlib's
strftime() is so lengthy that it would take quite an optimist to not
expect it to overrun any conventional paper format.

I don't want to make any promises, but we might be able to implement a
fairly cheap fix for this problem in grohtml early in the groff 1.24
development cycle.

Essentially, I want a "maxint" register and since "page length" is
conceptually an odd fit for HTML anyway, I'd very much like to
try out setting the page length on groff's "html" output device to the
value of that maxint register.

> It is docbook xml - see the previously attached xml and that in the
> attached archive.

Yes, the strftime.xml file looks like the DocBook I remember.  But...;a=blob;f=newlib/libc/time/strftime.c#l18

...does not.  I have a vague unease that information could be getting
captured there, at the ultimate source level ("the preferred form for
making changes to the work", as the GNU GPL puts it), that isn't being
done, making the generated DocBook less expressive and therefore
transformed more poorly into *roff/man/tbl.

Do you have a name for the inline documentation format with these double
angle brackets?  It isn't Doxygen or a literate programming markup
format I'm familiar with.  I can't even say for sure if I've seen it

> > > via makedocbook python script which generates xml (attached),
>        ^^^^^^^^^^^^^^^^^^^^^^^^^

Right...the DocBook that is the "source" for generating *roff et al. is
itself an intermediate format.  When I say "source" I typically mean
"the format you opened in your text editor to work on".

> > Personally, I lack confidence in DocBook to occupy this central role
> > in document format interconversion. Others on the groff list may
> > want to share their experiences.
> No options here - would have to redo the whole flow with available
> tools.  Wanted to replace all images with webp compressed for speed on
> mobiles but somewhere in the chain did not yet support those and
> stated they would never!


> I worked from your gbr suffix page, playing around with the test
> suffix, not getting far with html output anyway, and decided the only
> solution was to split the table, see suffixes -split (and -new for
> complete doc), which render properly in html and utf8, but groff still
> complains: run attached script for giggles.

Yes, I still get the format-time warning from tbl about the multi-page
boxed table, and, when formatting for HTML, the screeching from grohtml
about the suppression limit registers.

(It took me a long time, but I finally learned what that diagnostic
means, and I am uncertain that we really need to be throwing it.)

But the real fix for several forms of grief would be this:

> From the source code, it looks like the comment list delimiters are o+/o-
> (and o\s for list items), so adding a couple of those lines about where %Ox
> is in the table, should give us a split table that renders completely on all
> devices, of docbook cooperates.  ;^>

I'll take your word for it; the syntax you're quoting is utterly
unfamiliar to me.  I assume it is the unnamed double-angle-bracket
language I referred to above.

> I will ask the Cygwin groff package maintainer to give us a test
> preview, once you release, so we can check newlib, Cygwin, and any
> related doc flows.

Thank you very much!  I'm afraid I don't know who the Cygwin package
maintainer for groff even is at present.  It would be good to be
introduced.  It can be benefit to keep topological distances low.  :)

Incidentally, I advised groff's maintainer, Bertrand Garrigues, that I
am ready for RC3 or final release at his discretion.


Attachment: signature.asc
Description: PGP signature

reply via email to

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