lynx-dev frame and table rendering (was: "display partial" implementation in 'links')

[Vlad Harchev]

On Sat, 4 Dec 1999, Leonid Pauzner wrote:

> 4-Dec-99 15:12 Vlad Harchev wrote:
> > On Fri, 3 Dec 1999, Klaus Weide wrote:
> 
> >> On Thu, 2 Dec 1999, Leonid Pauzner wrote:
> >>
> >> > BTW, trying our competitor 'links' I was rather surprized:
> ...
> >> > The quality of HTML parsing is questionable but seems not bad.
> >> > Well, I found that table cells with href= are numbered this way
> >> > (starting from the top screen line, selecting via down-arrow key):
> >> >
> >> > xxx1    xxx4    xxx7
> >> > xxx2    xxx5    etc.
> >> > xxx3    xxx6
> >>
> >> I found that a real pain to navigate, except perhaps with a mouse.
> >> If you are on xxx1 and want to get to xxx7, you have to step through
> >> all the others first.
> >>
> >> Even with a mouse, there doesn't seem to be a way to select xxx7 without
> >> activing it.  For example, if I'm just interested in leaning where that
> >> link goes before deciding whether to follow it.
> 
> >  Very original, but since text comes by lines then columns, it could be easy
> > to hack links to order links as lynx does.
> 
> But if we got frames implementation some day the problem returns back
> when "left" and "right" frames happen to be on your screen. This will be
> a pain navigating without mouse anyway. What about links_are_numbered
> then?

 I said that it would be easy to hack 'links' so that links in tables to be
arranged first by line, then by colunmn (ie that 'links' could be made
behaving more like 'lynx', not vice versa).

 As for possible layout of links inside frames in the future 'lynx', IMO we
have the following solutions among others (I assume we will never get
per-frame scrolling if frame doesn't occupy entire screen):
 * we have to parse all frames (at least if frames are arranged vertically)
     before showing anything on the screen - as 'links' does.
 * draw all frames horizontally (ie no frames are allowed to be
     allocated as columns, only as rows - using my assumption above, this
     doesn't make any harm, but will make better appearance and will allow 
     partial display).
 * show each frame as separate document (rendered at full screen width) and
     introduce concept of 'lynx-frameset' - a group of related documents from
     user's point of view, with the name of each frame stored internally in
     lynx, with ability to quickly change between the members of such frameset
     may be by
        rendering  "frameset-parent" as lynx does now and providing command
        'go-to-frameset-parent' and forcing numbering of links that designate
        the members of frameset - so that each member in that frameset could
        be selected by number (may be with some prefix)
     "Target" attribute of 'a' and others should be respected - ie that named
     member of frameset should be replaced by document specified by 'href',
     not stacking new one.
       Such approach requires minimal changes to lynx, allows not to preload
     all frames, simplifies navigation for all types of users. IMO this can be
     rather easy to implement even now. Could somebody implement this?

 As for rendering tables, I think inventing another representation of htext
should be done in order to render them - something like this can be used:
I will call data representation type as "SText" used for this concept. With
this concept there is no meaning of line - only paragraphs and 
breaks (ie, imagine that the maximum allowed line length is 
infinite and HText structure is used, but with anchors embedded into it).
It's obvious that HText with embedded anchors rendered with infinite line
length could be rendered with any finite line length (algorithms are obvious - 
current HText_ methods could be used, and with HText_{begin,end}_anchor).

When rendering table, each cell is rendered as SText, and then cell width
is computed from STexts of cells belonging to that table. Then content of
each cell is rendered to HText (with computed line width) and HTexts 
of these cells are merged into single HText of entire table (color style
changes and anchors is the biggest problem).
      
Recursive table handling is not very difficult with this approach - the
most difficult is estimation of optimal cell width. Forms could cause some
problems, but they can be solved too.


   Have anybody looked at the rendering engine used by w3m and 'links'? I
think they use similar algorithms.
 
>[...] 

 Best regards,
  -Vlad