LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Autolayout algorithm in HTML Tables draft
From: Joe English <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Tue, 8 Aug 95 14:07:38 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (78 lines)




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 proof-of-concept.  (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 non-spanned 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 better-balanced 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]




Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager