LISTSERV mailing list manager LISTSERV 16.0

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


HTML-WG@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HTML-WG Home

HTML-WG Home

HTML-WG  August 1995

HTML-WG August 1995

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]



Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
January 1996
December 1995
November 1995
October 1995
September 1995
August 1995
July 1995
June 1995
May 1995
April 1995
March 1995
February 1995
January 1995
December 1994
November 1994
October 1994
September 1994
August 1994
July 1994

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager