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

[Vlad Harchev]

On Sat, 31 Jul 1999, Klaus Weide wrote:

> [ 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

 I'll write a message to lynx-dev and ask, whether we need to number each line
in textarea if "Links and Form Fields are numbered" - this is a thing that
makes any rendering unreliable - growing textareas force recalculation of
anchor numbers and possible changes the lenghtes of lines - and seems that
only textarea can grow.

> 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.


 But if horiz. scrolling is implemented, it will be easy to tweak old table
"rendering" code present in lynx now in order the table it renders to be
allowed to have lines wider than screen thus allowing your code to render
tables wider than screen.
 All that you can do now (in order to be ready for horz. scrolling) is to use
some other variable instead of LYCols - may be name it LYVCols, and put

#define LYVCols LYCols
  
> > 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...

 I was wrong when writing message to you saying that adding support for more
complex tables to your patch will be "not very difficult". Seems algorithms
involved in it will be completely different from the ones you are using.
 
>[...]
 
 Do you plan to implement suport for table borders?


 Best regards,
  -Vlad