[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Tables: getting started

From: Philip Webb
Subject: Re: lynx-dev Tables: getting started
Date: Fri, 19 Nov 1999 12:49:03 -0500 (EST)

991119 Klaus Weide replied to Philip Webb:
PW> assuming the basic 1-pass parse by Lynx, how could it handle tables
PW> to create something tabular & corresponding to authors' intentions?
> There are already some exceptions to the 1-pass of HTML handling
> Storing a copy of a TABLE and contents in a memory buffer or file,
> while it is first encountered, would be possible.  Probably awkward,
> and maybe not a good idea, but possible.  You don't *need* SOURCE_CACHE.

obviously: the word below is `recommended'.
it is surprising how many spurious objections people can find ...

> the problem is what to do with the stuff stored away
> and how to make the result fit Lynx's HText & anchor structures & lists.

see below: there's no reason at all to emulate Procrustes ...
> you envision (full) table rendering as a separate process.
> All the more reason to experiment with external scripts!

a reasonable point: so if i can do the job with 3 utilities from K+P,
you should be able to convert it to Lynx C code in an hour or two ... ?

> I see little reason why it *has to* be all done in the lynx code.
> You might as well dump the table mark-up into some file
> and let an external script deal with that
> ultimately feeding it back to lynx or not.

well, that's where Joe User pokes his mundane face above the parapet:
the alternative for him is not to find a script on the Internet,
download it, find out how to set it up as an external program,
then find out how to get Lynx to grab the result etc etc,
but simply to say: "Well, the developers admit Lynx can't handle tables,
so I'ld better use Notstraight or Exploiter for this kind of work".
i hope we have enough collective self-respect to reject that approach.
PW> to process a table, all Lynx has to do is
PW> find the right section of the source to process.
> There is no simple way to do this,
> if you think in terms of byte-count pointers into the raw source.
> Several layers of buffering separate parsing from the original byte form.

no, you're forgetting how the process is set up in the first place.
a user who has already compiled & enabled the necessary Lynx programming
sees a document with a table s/he wants to render more clearly
& activates TableSoup via the Options screen:
thereupon, Lynx re-renders the document, using source cache if available,
inserting a link corresponding to every <table>
& a bold  *** End of Table ***  for every </table>;
at the same time, Lynx can (if necessary) store
where these markers occur in both source & rendered versions
as a structure linking the corresponding places.

> Trying to fit all this into HTML.c or elsewhere in the usual processing
> is a big problem.  You'd want to do it in a separate stage,
> and that might just as well be implemented in an external process.
for development & testing, yes (as agreed above);
for daily Joe use, no (as explained above).

depending on other daily calls, pressures, surprises & whathaveyou,
you have probably provoked me into trying to show what i can do ...

SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]