Re: [Groff] tbl problems in man

[Eric S. Raymond]

Werner LEMBERG <address@hidden>:
> looking again at groff_mm.man, I see that using T{...T} in tables
> gives ugly results.  I think that this is a limitation of tbl which
> can't be worked around: For text blocks, you can't say `use the
> remaining line width' because they are processed earlier than the rest
> of the table.
> 
> With other words, as soon as we have table entries which need T{...T}
> -- and this happens quite often if the column contains more than a few
> words -- we can't use a table at all to get a decently looking result.
> 
> I see no solution to this problem.  Specifying a width argument to
> columns doesn't help either without a lot of troff register trickery
> to compute the correct width in advance.
> 
> Please revert to the previous formatting (I suggest using .TQ instead
> of .TP to avoid empty lines).  Doclifter might produce good results
> for HTML, but the visual degradation if formatted for other devices is
> not acceptable.

Ouch!

Yes, I could go back, find tables with T} in them, and revert them to
list markup and similar kluges.  But that would just bring us trouble
from another direction.  Many of the weird constructs I replaced with
tables (I'm thinking, for example, of the T2 macro in groff_mm.man)
will completely break manhtml and non-groff viewers.  That's why 
I moved a lot of this stuff to tables to begin with.

I agree that the T{ T} items on that page and some places elsewhere
don't look very nice -- the column widths are too narrow and the
entries look lumpy.  I was actually concerned about this myself.

But at least the tables will be readable everywhere.  I submit that
having the content be *completely* garbled by (for example) the GNOME
help browser is a worse result than the degradation in visual quality
you are seeing.  I think we actually need to either solve this problem
somehow or accept ugly-looking tables as the least-bad alternative.

Fortunately, I think I way around the problem constraints.  You say
"Specifying a width argument to columns doesn't help either without a
lot of troff register trickery to compute the correct width in
advance."  I think I understand that.  But what if we don't have to
specify the actual width?

Instead, let's steal a trick from the HTML book and implement a column
width syntax that specifies a fraction of total line width.  After
all, we will know \n[.ll] at the very start of table compilation.  We
can scale \n[.ll] by each specified column percentage during table
format processing, before T{ T} processing occurs.  Feed that to
whatever machinery is constraining the T block widths and we're done.

This seems like an elegant solution, unless I'm misconstruing something
very basic about how TBL operates.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>