Re: lynx-dev Re: Incorrect centering

[Chuck Martin]

On Sat, Apr 12, 2003 at 03:39:20PM +0900, Henry Nelson wrote:
> > said in response to Lloyd Rasmussen, it appears that this is part of Mr.
> > Senshu's mod to turn table centering on and of with ^Q.  It appears
> > that Mr. Senshu saw the same problem that I did, and decided to add an
> > alternate behavior instead of just changing the existing one.  I'm
> 
> I think a lot of his mods work that way.  Mostly he seemed to be doing
> it for himself to solve the problems created on a Windows environment and
> Japanese encodings.  It seemed as though he was intimidated a little by
> the main development tree, and preferred patching to actually asking for
> modifications to the source.  (Totally my personal interpretation.)

Most of the ^Q patch, however, isn't related either to Windows or to
Japanese encodings.  There is one small place where it prepends a '!'
to the string returned by the str_kcode() function, and that function
is only included if KANJI_CODE_OVERRIDE is defined, so that part would
be related to Japanese encoding.  I haven't had a chance to look at
that function in the rest of the code to see what it's purpose is or
how the prepended '!' affects the behavior of lynx, but most of the
^Q behavior affects all platforms in all languages and encodings.

> Now it's been so long, I've forgotten what had to be done.  (Maybe
> you could post about three lines of a rendered table, i.e., p)rint
> option, with table centering on, and with it off, using the ^Q toggle,
> in addition to with/without (default) your modifications.)

The difference between my patched version of lynx and the stock version
is identical to the difference between the two different behaviors that
^Q toggles between if SH_EX is defined, and this difference will only
be noticeable if there are cells in the table that have more than one
line.  In other words, the only tables that lynx handles properly (i.e.,
lines up the rows and columns of the table) are too simple to see any
noticeable effect.  The "tables" where the effect will be noticeable
are the ones where tables are used in a misguided attempt to "format"
a web page, like putting a column of buttons down one side of the page
to click on to go to other pages.

To show you what the current behavior does to text, I'll rewrite this
entire paragraph that you're now reading the way lynx would render it if
it was contained in a cell of a "table" that started with the tag <table
align="center">.

    To show you what the current behavior does to text, I'll rewrite this
   entire paragraph that you're now reading the way lynx would render it if
   it was contained in a cell of a "table" that started with the tag <table
                              align="center">.

That's not a worst case scenario.  I've seen paragraphs where the left
and right margins were a lot more ragged than that, and if you force line
breaks with <BR>, such as with poetry or addresses, they can be really
ugly.  That last line is a good example of how it makes things difficult
to read, because every time you finish a line, you have to hunt for the
beginning of the next line instead of just moving your eyes all the way
to the left margin where all of the lines begin in a straight line, and
this is especially irritating if the next line is the last in the paragraph
and is quite a bit shorter than the rest.

> I tend to think like you.  I really hate all that clutter in there when I
> do find a few spare moments to delve into the code.  I'm not keen on
> "remove" if you mean expunge from the code altogether.  Rather, I like to
> see those pieces commented out (/* ...  */), with an explanation why it was
> done.

In this case, I think "expunge from the code altogether" would be better,
because I believe the current behavior is totally wrong.  If other browsers
did as lynx does, I would say, "keep the ^Q modification, and remove the
ifdefs from it", but lynx is the only browser that does it this way, and
I don't believe the current behavior is now, or ever will be correct.  Even
if someone later adds better support for tables, the 'align="center"'
attribute in the <table> tag should be treated in a different manner than
it is now.

> I didn't see any comment from Tom on this thread, but then I got pretty far
> behind and kicked off the list because of the bounces.  Maybe ask a directed
> and short question again to Tom about what way he would like to see it
> handled.  My $0.02 would recommend disabling the whole centering mess by
> commenting out (not ifdefing).  I think that means adopting your patch(es)
> and, in addition, cleaning up the unneeded SH_EX #ifdefs (^Q toggle).

The patch I submitted previously was not intended to be a final fix.
All I did was enclose the offending code inside "#ifdef 0 ... #endif",
which basically means "do not compile this code under any circumstances",
so that others could try it out without losing that part of the code in
case they disagreed with me and wanted it back.  I think the correct fix
is to remove it altogether, as well as a few other sections related to
the ^Q modification, since that feature would no longer be necessary.
If everyone agrees, I would be more than willing to create a proper
patch that would do this.

> > is ever used in the <TR> tag, because I can't for the life of me figure
> > out why anyone would do such a thing.  How can you center a row as a
> > whole in a table?  How would the columns line up if you tried?  Is that
> 
> The kind of tables I seem to have trouble reading in Lynx are those that
> have a "O" or "X" for something like supported and not supported, e.g.,
>                  Solaris  NetBSD  FreeBSD  Linux  Windoze
>        Model 543    O        O       O       O       X
>        Model 024    O        O       O       O       X
>        Model 001    X        O       O       X       X
> 
> Doesn't Lynx do some thing like:
>    Solaris NetBSD FreeBSD Linux Windoze
>   Model 543 O O O O X
>   Model 024 O O O O X
>   Model 001 X O O X X
> 
> I haven't looked at the source of one of these for a long time, but I think a
> lot of them rely on align="center" kind of stuff to get the effect they want.

I don't think they do, but if you find one that does, let me know.  The
reason for that behavior is that if the table is too complex for TRST,
lynx just inserts a space between the last character of one column and
the first character of the next column, which I think could be improved
even without true table support.

> Anyway, it would be nice if Lynx wouldn't scrunch everything to the left.

Or maybe use something else to separate the columns that isn't likely to
be found in a cell (like maybe " :: ").  The columns still wouldn't line
up, but you could more easily figure out what should be lined up under
what.  A space used to separate columns can't be distinguished from a
space used in the contents of a cell.  If the table is simple enough,
the columns will line up properly, but it must be VERY simple (no multi-
line cells, for example, and no rows too wide to fit on the screen).

By the way, I just tried <TR ALIGN="CENTER"> with all of the browsers I
have installed, and it seems that they all do as lynx does, centering
each cell in the row line by line, but none do if the align attribute
is in the <TABLE> tag itself, so maybe we should leave the <TR> behavior
alone and just change the <TABLE> behavior.  I don't know if the <TR>
version is found anywhere in the wild or not, but since neither behavior
makes any sense in that case, I don't really care what it does.

Chuck


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden