Re: lynx-dev lynx and tables, looking for more information...

[Klaus Weide]

On Tue, 15 Feb 2000, Vlad Harchev wrote:

> 1)  If, for each row, total width of all cells in a row is less than screen
> width (without wrapping contents of the cells), then table is rendered
> in a usual (for human) tabular form.
> 2)  If some cell has forced line break (ie <p> or <br>) that cell will be
> displayed in several lines, and the rest of table will be displayed depending
> on the 1).
> 
>  Otherwise, table is rendered as html with html table markup stripped (ie 
>  as if all <td> and <tr> were removed) - ie such thing is very difficult
>  to read.

Not really - Lynx at least always inserts a blank for each <td> and a line
break for each <tr>.  What I called "LYNX minimal table support" in
README.TRST.  Without that, things would be worse.

> 
>  File /docs/README.TRST contains a detailed info on this.
> 
> > Are there things I can do to customize table display results?

(I assume you mean as a Lynx user, not as a page author.)

>   No (unless you preprocess the html using some script that simplifies table 
> structure).

Yes - If you have the choice (by using Lynx in an xterm, for example),
increase the screen (window) width, that will allow some tables to
"fit" that otherwise wouldn't.

> > I'm also interested in hearing more about the problem from a
> > developer's standpoint and what the issues are with solving it.
> 
>   The lack of time, complexity of the internal lynx structures used for
> representing html (in few words, it's just a rendered text and nothing more, 
> it's rendered on the fly as html comes from the net), and deep
> internationalization - the wide use of unicode and various CJK encodings - and
> the fact that international symbols (in the wrong case) are stored as
> multibyte (= variable length) characters.

I don't think that the intenal use of unicode and CJK encodings has been
preventing anybody from implementing full(er) table support.  If it worked
with ASCII characters only, the remaining tweaking could be done later.


The most basic reason why Lynx doesn't have fuller table support is
that nobody has done it.  Reasons for *that* - 1) it isn't easy (but
certainly a solvable problem, as other browsers show, if someone wanted
to invest a lot of time) 2) It's harder to add this to an existing app
(where it doesn't fit very well with the way things are done - one-pass
processing etc.) 3) (speculative) it's not an interesting enough problem
to attract someone to do it.

   Klaus