> I've enclosed the test load I use. To see the behavor under the
> existing default, remove the 'experimental' flags from the table
> headers.
I've just fixed another bunch of errors in the C++ code; however, the
computation is still not correct.
Reason for this, I think, is that the algorithm used to compute the
text block widths is too simplistic.
Look at the first table in `TEST' which uses T{/T}: Using the PS
output device, we have an effective line length of 396000u, and we get
minimal widths `3w0' (16560u) and `3w1' (224390u) for the first and
second column, respectively. Since the second column also contains a
text block, its width must not take part in the computation of the
text block width. Consequently, the width for the text block is
396000u - 16560u = 379440u. Because this value is larger than `3w1',
we are done for this table. Looking at the code it seems that your
changes to tbl don't do this correctly yet.
Now assume that we have a table with three columns (using the same
effective line length as above):
column 0: 3w0 16560
column 1: 3w1 224390 -> contains at least one text block
column 2: --- -> contains only text blocks
This gives (396000 - 16560)/2 = 189720 as the width for the text
blocks. However, this value is smaller than `3w1'! It means that we
have to increase the text block width of the second column to 224390,
and to subtract the difference from the third column:
189720 - (224390 - 189720) = 155050
With other words, we have 224390 as the width for the text blocks in
column 1 and 155050 for column 2.
Extending this procedure to more columns, we get this iterative
algorithm:
1. Compute all fixed column widths.
2. Sum up the space used by columns which don't contain text blocks.
Use this to compute the default text block width.
3. Check against the columns which contain both text blocks and
fixed column widths. As soon as we find a fixed width which is
larger than the default text block width, mark this column as
fixed (this is, handle it as if it doesn't contain a text block).
Restart with item 2.
tbl doesn't handle this case at all; however, it is quite trivial to
implement I think. Most of those steps have to be coded as troff
code. I'm not sure whether this algorithm can be represented as
non-iterative, which would make the troff output considerably shorter.
Werner
