Re: Side scrolling [was Re: LYNX-DEV Re: Setting up a fund ...]

[Lloyd G. Rasmussen]

On Mon, 12 Jan 1998 00:18:37 -0600 (CST), 
Filip M Gieszczykiewicz   <address@hidden> wrote:

>You (Nelson Henry Eric) wrote:
>>> The problem though with side scrolling is that it is an expensive operation
>>> in terms of line time for freenets and the like (I'm not sure if curses can
>> 
>> Sorry to keep making references to "most", but it does side scrolling
>> and seems to be so "light".  It's slang-based, which I assume means it
>> could be done with curses easily enough.  Being a dreamer and not a
>> programmer, it almost seems that (a) side scrolling function(s) could,
>> even by option, be compiled in, and have Lynx feed its parsed output
>> to that/those function(s).  (Analogous to the zlib support that Klaus
>> worked in.)
>
>That's what I was thinking... I'd hack the parser of the tables to just
>slug them into an array for each line... making sure to mark empty
>cells to keep track of columns. Then, pass the whole thing to a
>function (or a whole _mode_ of lynx) which would reparse this looking
>at all the columns in turn and figuring out the maximum length of
>fields and adjusting the width to that... and displaying it on the
>screen with calls to a [modified] filter that would remap the virtual
>display "screen" to the real terminal screen (not sure if ncurses does
>that). Then, when "view tables" module is exited, free all the memory
>associated so nothing is wasted. And you got yourself _my_ idea of a
>2-pass parser :-)
>
>I, for one, would not care if this had to _redraw_ the whole screen
>NOR would I care if it took lots more CPU cycles and swaping to
>get it up on the screen. Once something that horribly inefficient
>is written we BOTH have the TODO's table-support checked off AND
>it's an excellent base for someone to come along and optimize it!
>

Some kind of table support would be useful.  It, like many other 
aspects, would be useful to be able to maintain Lynx's current 
behavior for tables, because the current behavior is very useful for 
sites such as www.news.com/ which don't use frames but do use tables 
with <br> tags in them.  In News.Com, Lynx displays the left column, 
then the center text, then the right column, and it is a pretty clean, 
"logical reading order" display.  So for some pages, I prefer the 
current behavior.

But for many other pages, we need tables.  My favorite example is 
train and bus schedules, but things can get a lot more complicated 
than this, what with HTML allowing nested tables and many kinds of 
elements within table cells.  

If someone were to work on this, they ought to look at the extensive 
discussions of the Web Accessibility Initiative, where Al Gilman has 
been participating.  There are new constructs in HTML 4, partly as a 
result of these discussions, so that columns can be grouped, and I 
think there are also provisions that would allow you to scroll some of 
the data on the rows while leaving the row label fixed.  

As a screen reader user, I would want fairly large chunks coming onto 
the screen, such as a table column or a table column group, rather 
than bits of words and characters.  If the parser successfully divided 
the columns of a table, it might be useful to put a vertical rule 
between the cells, (a vertical line character) as well as one or more 
spaces (preferably more).

I know that table support isn't going to happen any time soon, if 
ever, but thought I'd at least get some ideas into the archives.

-- Lloyd Rasmussen
Senior Staff Engineer, Engineering Section
National Library Service for the  Blind and Physically Handicapped
Library of Congress          202-707-0535
(work)       address@hidden    http://www.loc.gov/nls/
(home) address@hidden http://home.sprynet.com/sprynet/lras/