Re: lynx-dev frame and table rendering

[rjp]

In message <address@hidden>, 
           Klaus Weide writes:
> (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.)

My styles code already does that.  

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

Yes, that's exactly it.

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

Well, that brought up a thread about SGML.c for me, which isn't relevant 
at all as far as my point goes.  I don't care how the page is split
into elements, be it SGML.c or PinkElephant.c, so long as we get a full
parse tree for the document out of it.  That way, we can handle things
like tables, Javascript and stylesheets properly.

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

Only if you don't want to have to keep re-rendering your document, yes.
I'll settle for re-rendering to start with, since that's the simpler
goal.

"Make it work, then make it fast" - D.E.Knuth
-- 
rob partington % address@hidden % http://lynx.browser.org/