Re: lynx-dev lynx and tables, looking for more information...

[Vlad Harchev]

On Wed, 23 Feb 2000, Duncan Simpson wrote:

> 
> <stuff snipped>
> 
> The table layout code I have likes entries in ASCII format seperated by \n in 
> appropiate places. It uses this informaition to draw the table line by line, 
> from left to right. Tables wider than the screen are not a problem. It has 
> been well tested to work nicely by some M$ word tables.
>  
> > If I understand you right, you have some code for tables but it would
> > require a "function to render something with a given width" that would
> > be supplied by the Lynx code.  I assume with "render into" you mean 
> > everything including line breaking logic..
> 
> Yup, right. It would also have to be willing yto render the body of the table 
> twice; the first time the table layout logic works out what width the columns 
> want and how wide a table that means. The second pass specifies actual widths 
> if required so it fits nicely.

 Two passes is OK - it's unavoidable IMO.

> Subtables should be easy enough if this code was well integrated, all that 
> needs to happen is a request to render the included text with width x. I 
> guess 
> the same code could be adapted to layout frames, albeit with implications 
> about where the "real work" of the code appears.
> 
> >Unfortunately, there is no such
> > function currently in the Lynx code.  Splitting text into lines is done
> > in the simplest case (no relevant markup that affects line breaking) in
> > GridText.c or, in more complex cases, in HTML.c in cooperation with
> > GridText.c functions; but all this uses a global variable LYcols for the
> > available width (which is the full screen width), there are no provisions
> > for "rendering" into smaller columns of text.
> > 
> 
> This is bad news, should I wait for it to change? I have plenty of "real 
> work" 
> and word2x stuff to be getting on with in the mean time. I just thought some 
> re-inventing that particular wheel was silly (the source file is 300 lines of 
> C++, which could be quickly turned into C).

 I don't think that global variable LYCols is a problem. We can
#define LYCols text->LYCols
 or something like this, without breaking anything.

 Does your code handle col spans and row spans well? That could be a tricky
thing in pathological cases, that could require 3rd pass.
 Anyway, at least I will be glad to see the code (even C++) - I guess
understanding algorithm implemented in C++ will be easier, than reading
existing code of w3m or 'links' or gecko where the logic is spread over
thousands of lines.
 Thank you in advance.

> -- 
> Duncan (-:
> "software industry, the: unique industry where selling substandard goods is
> legal and you can charge extra for fixing the problems."
> 

 Best regards,
  -Vlad