#766458 lynx-cur: some tables are not rendered correctly

#766458#5
Date:
2014-10-23 09:10:48 UTC
From:
To:
The attached file contains two similar tables, but the second one is
rendered incorrectly:

   Table 1:

 A: 123456789 123456789 foo
 B: 12345678            foo foo foo foo foo foo foo foo foo foo foo foo foo foo
                        foo foo

   Table 2:

   A: 123456789 123456789 foo
   B: 1234567 foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
   foo

while Table 2 should have been rendered as:

 A: 123456789 123456789 foo
 B: 1234567             foo foo foo foo foo foo foo foo foo foo foo foo foo foo
                        foo foo

I initially saw this problem on:

http://www.ens-lyon.fr/LIP/AriC/membres.html

(first table rendered correctly, not the second one).

#766458#12
Date:
2015-06-04 20:27:48 UTC
From:
To:
tags 766458 unreproducible moreinfo
thanks

Hello Vincent,
Thank you for your bug report.
I can't reproduce this bug.
The attached file contains exactly the two similar tables.
Where is the issue?
The provided URL have a 404 error.

Best regards

Denis Briand

#766458#17
Date:
2015-06-04 20:27:48 UTC
From:
To:
tags 766458 unreproducible moreinfo
thanks

Hello Vincent,
Thank you for your bug report.
I can't reproduce this bug.
The attached file contains exactly the two similar tables.
Where is the issue?
The provided URL have a 404 error.

Best regards

Denis Briand

#766458#22
Date:
2015-06-04 21:19:35 UTC
From:
To:
On my Debian/unstable machine, both tables are now rendered incorrectly.
On an Ubuntu 14.04.2 LTS machine, both are rendered correctly.

The first "foo" on each line should be vertically aligned.

This URL is now obsolete. What matters now is the attachment.

#766458#27
Date:
2015-06-04 23:51:15 UTC
From:
To:
Note: the test must be done in a 80-column terminal, otherwise the
result is not reproducible.

I confirm with a 80-column terminal, i.e. something has changed
between 2.8.9dev.1 and 2.8.9dev.6, but in a more incorrect way.

Actually no, with a 80-column terminal, only Table 2 is rendered
incorrectly.

#766458#42
Date:
2023-04-26 13:41:36 UTC
From:
To:
Control: found -1 2.9.0dev.12-1
Control: tags -1 unreproducible

I suspect that the test was done with a wider terminal.
So removing the "unreproducible" tag.

I recall that the testcase is the attached file at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766458#5

i.e. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=766458;filename=tables.html;msg=5

lynx 2.9.0dev.12-1 still produces

   Table 1:                                                                    ▮
                                                                               ▮
   A: 123456789 123456789 foo                                                  ▮
   B: 12345678 foo foo foo foo foo foo foo foo foo foo foo foo foo foo         ▮
   foo foo                                                                     ▮
                                                                               ▮
   Table 2:                                                                    ▮
                                                                               ▮
   A: 123456789 123456789 foo                                                  ▮
   B: 1234567 foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo      ▮
   foo                                                                         ▮

while ELinks is correct, for instance:

   Table 1:

   A: 123456789 123456789 foo
   B: 12345678            foo foo foo foo foo foo foo foo foo foo foo foo foo
                          foo foo foo

   Table 2:

   A: 123456789 123456789 foo
   B: 1234567             foo foo foo foo foo foo foo foo foo foo foo foo foo
                          foo foo foo

#766458#49
Date:
2023-04-26 13:53:49 UTC
From:
To:
Control: tags -1 - unreproducible

Now doing it correctly...