Re: [Groff] tbl problems in man

[Eric S. Raymond]

Werner LEMBERG <address@hidden>:
> What's the problem with .TQ?  Most of the data in groff_mm.man can be
> represented with this macro in a satisfying way, I believe.

Since you say so, I assume it's possible.  But I have not figured out
how yet.
 
> > Instead, let's steal a trick from the HTML book and implement a
> > column width syntax that specifies a fraction of total line width.
> 
> Example, please.  It's not completely clear to me what you want to do.

OK.  But first, even if we don't find a way to implement what I'm about 
to suggest, I've experimented and verified that the lumpy tables can be
fixed by adding a w format to the bad column's format spec.

Here's the start of one of the tables that looks wrong.

            Df register

                     0   Displays  are  printed  at
                         the end  of  each  section
                         (when section-page number���
                         ing is active) or  at  the
                         end of the document.
                     1   A  new  display is printed
                         on  the  current  page  if
                         there   is  enough  space,
                         otherwise it is printed at
                         the end of the document.

And here's how it is set:

.TS
tab(@);
l l.
address@hidden
Displays are printed at the end of each section (when section-page
numbering is active) or at the end of the document.
T}
address@hidden
A new display is printed on the current page if there is enough space,
otherwise it is printed at the end of the document.
T}

If we say this instead:

.TS
tab(@);
l lw50.

we get this:

         Df register

                     0   Displays  are  printed  at the end of each section
                         (when section-page numbering is active) or at  the
                         end of the document.
                     1   A  new  display  is printed on the current page if
                         there is enough space, otherwise it is printed  at
                         the end of the document.

So we know we can get decent-looking tables with a little
hand-hacking, and I'll go in and do that if I have to as an
alternative greatly preferable to going back to nonportable custom
macros like T2.

The only problem with using w is that the number that needs to go to go next 
to it is brittle -- it may break if the table indent changes, or if the
the point size changes, or if the margins change.  But even with those
limitations, it takes the pressure off this discussion.  I won't have
to rip out half my port changes, and you won't have to consider tbl
desperately broken.

Instead, we can talk about how to teach tbl to be smarter about computing
width defaults, and about ways to override the width defaults that are
less fragile than an absolute column width.

If my understanding is correct, TBL picks a random value for the
maximum width of the T{ T} block because T{ }T blocks are processed
before the rest of the table, so TBL can't know how much horizontal
space is going to be left when the other columns have claimed their share.

But now imagine that the w specifier takes a percent syntax that looks like 
this:

.TS
tab(@);
lw10% lw90%.
address@hidden
Displays are printed at the end of each section (when section-page
numbering is active) or at the end of the document.
T}

We have just said "Give column 1 10% of the maximum available table
width.  Give column 2 90% of it."  The maximum available table width
is basically A = (\n[.ll] - \n[.in]).  At the time we parse each
percent spec, we multiply it by A.

Now we can force good behavior without having to care about the
current indent, or point sizes, or margins, or how they might change.
This trick is shamelessly stolen from the percent-spec form of
table width in HTML.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>