Re: lynx-dev frame and table rendering

[Klaus Weide]

On Mon, 6 Dec 1999 address@hidden wrote:

> In message <address@hidden>, 
>            Klaus Weide writes:
> > They already are separate; parsing: SGML.c; rendering: all the rest...
> >
> > IOW, your terminology is confusing.
> 
> Well, ok.  I was using "parsing" as "parsing the HTML into elements",
> not "parse the HTML into SGML bits and bobs".  In that sense, the
> parsing and rendering are not seperate because HTML.c performs some
> rendering, and is called by the parser (start_element, end_element).

Well I suggest to reserve "parsing" for what SGML.c does.  That seems
to be more "standard" usage for things that deal with HTML, don't you
think?

> IMO, they're not seperate since you have to render whilst parsing.
> You don't get a chance to do anything with the parse-tree.

But see the positive side, it's elegant and quick...

(You could at least know what the containing elements are at any point,
if that helps you for something.  Althou that isn't currently used
anywhere in generality, except for some stuff within SGML.c, so there's
no interface to get that info.)

> > > So parse->internal objects->renderer->HText->curses|slang->screen?
> > 
> > What's left of your "parse"?
> 
> The same as before.  Lynx doesn't create internal objects now, just
> passes the parse information straight to HTML.c for rendering.  In
> this scheme, HTML.c wouldn't render anything, just create an internal
> representation of the document which would then be rendered by a seperate
> mechanism which can then take advantage of full knowledge about the
> parse-tree.
> 
> Does that make more sense?

Well I guess that means you'd have on HTML.c-in that has (more or less)
the current HTML.c's "incoming" interface (the side that SGML.c sees),
and an HTML.c-out that has the current HTML.c's "outgoing" interface
(makes calls to HText_*() similar to the current HTML.c).  And in between
a new memory representation of the document.

These ideas aren't completely new, even for lynx-dev; see the threads
starting here:
  <http://www.flora.org/lynx-dev/html/month0497/threads.html#00826>
(No I didn't read it all again, so I don't know exactly how relevant
it is now.)

Whatever you do, if you keep the HText implementation in some form,
you have to add something to it, at least some added info that points from
a given point in the "rendered document" back to the corresponding point
in the to-be-invented intermediated representation, right?

   Klaus