[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Groff] Re: another tbl peculiarity
From: |
Gunnar Ritter |
Subject: |
[Groff] Re: another tbl peculiarity |
Date: |
Sat, 08 Nov 2008 13:09:32 +0100 |
User-agent: |
Heirloom mailx 12.5pre 10/4/08 |
Werner LEMBERG <address@hidden> wrote:
> Hmm. While GNU tbl's output is debatable -- it is not documented
> whether minimum width values should be used if a text block span
> contains at least one column *without* a minimum width -- I think that
> heirloom's output is really buggy. Even for a table specification
> like
>
> lw(3n) lw(9n) lw(3n)
> l s l.
>
> heirloom tbl only applies the first column width to the whole text
> block span. This essentially prevents the use of text block spans, so
> I doubt that you should take care of `unexpected changes in existing
> documents'.
It is always possible to have an explicit .ll in the text block,
though. This is also what Lesk's tbl manual advises:
| If no line length is specified in the block of text itself,
| or in the table format, the default is to use LxC/(N+1) where
| L is the current line length, C is the number of table columns
| spanned by the text, and N is the total number of columns in
| the table.
Because this rule is too simplistic for most cases, Bell Labs
tbl requires a .ll for most text blocks anyway. The problem
here is that tbl puts a text block into a formatted diversion
before the actual column widths have been computed, so it can
only guess what they are.
Gunnar
Re: [Groff] another tbl peculiarity, Tadziu Hoffmann, 2008/11/07