Bert Bos <[log in to unmask]> wrote:
> Joe English writes:
> I move that Jon's algorithm be incorporated into the Tables draft.
>
> Sorry Joe, but I don't understand this. There are actually a number of
> different ways to compute the cell widths in case columns are
> spanned. All of them produce acceptable results in 90% of the cases,
> Jon's algorithm is just one of the possibilities.
True; I just think that the spec should say *something*
about how to treat spanned columns (if it's going to include
the autolayout algorithm at all). I don't believe the algorithm should
be normative, it just has to provide a proofofconcept. (Nor do
I think Jon's algorithm should be the only one mentioned; the ones
you describe below are also worth including.)
> Instead of dividing the width of the cell by the number of columns,
> you can also subtract the widths of the columns and then divide the
> remainder (if positive) over the columns.
On the plus side, this would produce a more compact layout in
many cases: say a column with natural width 20 spans a column
of width 3 and a column of width 17; Jon's algorithm would expand
the first column to width 10, while this algorithm would not widen
the table at all,
One drawback is that it requires two (or maybe more?) passes:
one pass for the nonspanned columns and a second pass for the
spanned cells.
Jon's algorithm will always give the same layout, regardless
of what order the cells are examined; that may be a desirable
feature. With a separate readjustment pass for spanned columns,
it'd take some care to make sure that this was still the case.
For example, see Knuth's algorithm for width computation on p. 245
of the TeXbook (towards the end of Chapter 22); that's O(n^2).
What about a case like:
<table>
<tr> <! row with short cells >
<td>1
<td>2
<td>3
<tr>
<td colspan=2>This cell spans columns one and two
<td>this cell is in column three.
<tr>
<td>this cell is in column one
<td colspan=2>this cell spans columns two and three
</table>
Jon's algorithm would give betterbalanced columns than does
Netscape 1.1 or Mosaic 2.7 on this table; it appears that they're
using an algorithm similar to the one you described. I can't
tell *what* Arena 0.97 is doing with it, but it definitely looks
the best.
> You can also add the
> remainder to the first column, or to the last, or to the one in the
> middle. You can also divide the remainder over the columns in
> proportion to their width. Etc.
Dividing the remainder proportionally sounds promising.
That still requires two or more passes to calculate widths.
> So, which one of these is best? Or is there an even better algorithm?
Joe English
[log in to unmask]
