Closed
Bug 23034
Opened 25 years ago
Closed 24 years ago
Strange wrapping behaviour with non Latin1 char in nested table (see html file in the description)
Categories
(Core :: Layout: Tables, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
M17
People
(Reporter: ciopz, Assigned: buster)
References
Details
(Keywords: testcase, Whiteboard: [TESTCASE] [probable dup])
Attachments
(2 files)
<html> <head> <meta name="Author" content="Andrea Salmaso - ciopz@iname.com"> <TITLE>"Nested table wrap bug"</TITLE> </head> <body> <table border=1> <tr> <td> This two yellow tables have the <EM>identical</EM> HTML code. IExplorer 4 and Netscape 4.7 render the two tables identically. Mozilla M12 seems anyway render the first column with two rows cells, instead of one row cells as -presumabily in respect of HTML rules- it renders in the second copy of this table. <br>This seems due to the nesting the table into another table. <br>The rend.eng. wrap cells <EM>without</EM> the "NOWRAP" attribute (i.e. setting this attribute in any of these cells solves the problem). Note anyway the content of these cells shouldn't (right?) be wrappable:<br> <DIV align=center>&nbsp;•&nbsp;</DIV> Does maybe Mozilla consider the character &149; (a non printable char in the Latin-1 char codes) the same way the space character ? Is this a bug ? <br>Why this behaviour is no more valid when the table is not nested ? </td> <td> <table BORDER=1 BGCOLOR="#FFFFCC"> <!-- ##### Start First "nested" Table ##### --> <tr> <td COLSPAN="3"><br><!-- --><b><i><font size=-1>go to:</font></i></b></td> </tr> <tr VALIGN=TOP> <td> • </font></td> <td NOWRAP><font size=-1>Control columns</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </font></td> <td NOWRAP><font size=-1>Leave columns alone</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Restrain rows</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Rowspans made easy</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Baseline your text</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Fill cells for Navigator</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Centering tables</font></td> <td> </td> </tr> </table> <!-- #### End First table #### --> <!-- border #666633, text #cc0000 --></td> </tr> </table> <P> <table BORDER=1 BGCOLOR="#FFFFCC"> <!-- #### Start Second ("free") table #### --> <tr> <td COLSPAN="3"><br><!-- --><b><i><font size=-1>go to:</font></i></b></td> </tr> <tr VALIGN=TOP> <td> • </font></td> <td NOWRAP><font size=-1>Control columns</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </font></td> <td NOWRAP><font size=-1>Leave columns alone</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Restrain rows</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Rowspans made easy</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Baseline your text</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Fill cells for Navigator</font></td> <td> </td> </tr> <tr VALIGN=TOP> <td> • </td> <td NOWRAP><font size=-1>Centering tables</font></td> <td> </td> </tr> </table> <!-- #### End Second table #### --> </body> </html>
|
||
Comment 1•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Whiteboard: [TESTCASE]
|
|
||
Comment 2•25 years ago
|
||
The problem seems to be: if a bullet is placed between two in a cell in a nested table, the bullet ends up on a second line, whereas if the cell is in a table that is not nested, the bullet ends up on the first line inside that cell. Confirmed with: 2000-01-05-08-M13 nightly binary on Windows NT 4.0sp3
|
||
Comment 3•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
|
||
Comment 4•25 years ago
|
||
|
|
||
Comment 5•25 years ago
|
||
In the 2nd attachment, during a resize reflow the 1st cell's block in the nested
table containing the bullet character is requesting too large a desired height
(570 twips = 38 pixels). Reassigning to Kipp's bug list.
TC::Rfl 00DD0478 rea=2 av=(1979,UC) comp=(1919,UC) count=22
Area::Rfl en 00DD04D4 rea=2 av=(1919,UC) comp=(1919,UC) count=23
TO::Rfl en 00DD0558 rea=2 av=(1919,UC) comp=(1889,UC) count=24
T::Rfl en 00DD05AC rea=2 av=(1919,UC) comp=(1889,UC) count=25
TRG::Rfl 00DD0618 rea=2 av=(1889,UC) comp=(1889,UC) count=26
TR::Rfl en 00DD0658 rea=2 av=(1889,UC) comp=(1889,UC) count=27
TC::Rfl 01C53038 rea=2 av=(269,UC) comp=(209,UC) count=28
Area::Rfl en 01C53094 rea=2 av=(209,UC) comp=(209,UC) count=29
Area::Rfl ex 01C53094 des=(209,570)
TC::Rfl ex 01C53038 des=(269,630)Assignee: karnaze → kipp
kipp is very unlikely to fix these, since he's not working ont he project any longer. so I'll take a look.
Assignee: kipp → buster
almost certainly a dup of 14280, which I already have a fix for. setting up the dependancy, so I can verify when I get back to the office.
Depends on: 14280
Whiteboard: [TESTCASE] → [TESTCASE] [probable dup]
WFM. Was probably a dup of 14280.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•