[Groff] another tbl peculiarity

[Werner LEMBERG]

Again some strange results from the undocumented parts of tbl.

Look at this table:

  .ll 36n
  .TS
  tab(;);
  lw(3n) l lw(3n)
  l      s l.
  a a;T{
  b b b b b b b b
  b b b b b b b b
  T};c c
  T{
  d d d d d d d d
  d d d d d d d d
  d d d d d d d d
  d d d d d d d d
  T};e e
  .TE

Which gives this result if formatted with `groff -t -Tascii':

  a a    b b b b b     c c
         b b b b b
         b b b b b
         b
  d d d d d d d d  d   e e
  d  d d d d d d d d
  d d d d d d d d  d
  d d d d d

The first row of this table shows the expected width of the middle
column: 36n*1/(3+1)=9n.  However, the width of the span of the first
and second column in the second row is unexpected, at least for me: It
is 36n*2/(3+1)=18n.  Instead of this, I would have expected that it is
3n + 36n*1/(3+1)=12n.  In other words, the minimum width value of the
first column is completely ignored, and only the default width value
for text blocks is applied.

Note that heirloom's output is worse (I've used a compiled CVS version
from 2007-Jan-09).  Using `tbl | nroff -Tlp' I get

  a a               c c
  [7      b b b b b
        b b b b b
        b b b b b
        b
                    e e
  [7d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d
  d d

<note>
  The `[7' is actually `<ESC>7' -- looks like a bug...  Supposedly it
  should move up one line.  However, neither `less' nor my xterm
  console understand this, and it isn't helpful for output redirected
  to a file.
</note>

Apparently, heirloom's tbl uses the minimum width of the first column
for the whole span.

Do other tbl implementations give better results?  I think I'll fix
GNU tbl accordingly.


    Werner