lynx-dev state of TRST (was state of TSST)

[Klaus Weide]

[ responding to private messsage, quoted with permission: ]

On Fri, 30 Jul 1999, Vlad Harchev wrote:

>  Hello Klaus!
> 
>  In recent message you said that you haven't completed TSST for lynx. I'm
> wondering - seems you spend a lot of time on it - and it's incomplete yet.
> How it can be? What are the problems?

It works quite nicely for really "simple" tables.  Main problems are with
the logic for hybrid tables, it ended up in a lot of logic I hardly
understand myself, which is still incomplete, and for diminishing
benefits.  Also in the end it ought to work resonably with TagSoup as well
as SortaSGML mode, which isn't currently the case.  I keep testing with
various pages, trying to understand why the code I created acts the way it
does, spending some quality time with my debugger.  It's tempting to do
something else though.

In the process of testing I also found some logical errors in the way
anchor positions are adjusted, that became only visible in some test
tables with several anchors per line and/or only in one links_are_numbered
setting.  It's like a law of nature, one cannot do after-the-fact changes
of the HText structure without introducing obscure errors.  Then there's
an error I found in my understanding of what the ALIGN attribute on a
<TABLE> should mean (alignment of the table as a whole vs. alignment of
cells).  So I'm kind of glad I didn't yet "publish" the "works well enough
for really simple tables" code, because it saved me from having to send
a number of fixes. 

Add to that that I'm in Chicago without air condition, with sweat dripping
into the keyboard if I'm not careful...

>  Currently, I don't have time to invest it in (sorry), but can provide some
> advices on it. Here are my notes:
> 
> 1) Seems that adding horizontal scrolling in GridText will be very easy
>    (comparing to what you are doing). I suggest you to provide means for easy
>    integration of this in your patch (but seems that even with support for
>    horz. scrolling the code you are working on will produce rendered tables
>    with the exact number of lines they'l have in old lynxes).

I don't know whether horizontal scrolling will be "very easy".  But I
assume the implemention would change mainly just the very "late" stage
- display_page, display_line - and would not affect the earlier stages
of building a representation of a page, apart from letting them know that
they can build longer lines.  Since my code for re-shifting parts of lines
doesn't act at the display_* stage but earlier, it has little to do with
the hypothetical horizontal scrolling mechanism.

> 2) From my quick analysis it seems that adding the support for rendered
>   versions of tables with number of lines different from number in "dumb old
>   rendering" is not very difficult (I mean may be you should modify approach
>   you are using - add computed number of spaces in some positions in each line
>   and get better look - and think on rendering in more complex cases, where
>   the number of lines of "pretty tables" will be different from number of
>   lines of "dumb old algorithm result"? 

I stick to the limited problems of my limited approach for now.  Once THAT
works, fell free to tweak it...

>                                          Remember, with support for horizontal
>   scrolling the key feature of TSST - equal number of lines - will be
>   redundant and limiting. Think of hyphenation - this will give more possible
>   values for the width of a given column.
>      I know that hightext handling of links will be the most difficult to
>   implement, but we can highlight only anchor text in the 1st line of the cell
>   - since current anchor hightext model allows only "continous" hightext).

The limited approch doesn't have this problem (except for bugs), one more
reson for pursuing it first.

>      At least provide a mean for relatively easy "deintegration" of you
>   changes (possibly by using cpp conditionals) in order support for more
>   generic cases to be added.

Although I don't have this ifdef'd, "deintegration" is simple.  Omit just
one call (HText_startStblTABLE in HTML_start_element), and the whole
machanism never gets triggered.  The interface between existing code and
added code is narrow, the bulk of new code is in a separate source file.
Only a few function calls, no tight integration, GridText.c and new code
don't have knowledge of each other's internal data structures.

It seems to me that adding support for what you mentioned would remove
most or all of that separation.  Not that I know how to do it at all; but
I know even less how to do it by "adding support" to the TRST approach.

TSST -> TRST, s/support/representation/  (or "rendering" if you prefer).
"Support" doesn't say much (or the wrong thing), basically just a filler,
so I am changing the acronym for this vaporware product. :)
Scratch symmetry.

   Klaus