Bug 153405 - Table in 2nd column wrongly split over page break; unstable rendering
Summary: Table in 2nd column wrongly split over page break; unstable rendering
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2023-02-06 05:44 UTC by Jim Avera
Modified: 2024-09-24 11:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
tablesplit1.odt (see STEPS TO REPRODUCE) (24.60 KB, application/vnd.oasis.opendocument.text)
2023-02-06 05:44 UTC, Jim Avera
Details
exploded_screenshot.png (84.24 KB, image/png)
2023-02-06 05:44 UTC, Jim Avera
Details
after_save_reload.png (67.32 KB, image/png)
2023-02-06 05:46 UTC, Jim Avera
Details
tablesplit1_screenshot.png (111.01 KB, image/png)
2023-02-06 05:57 UTC, Jim Avera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2023-02-06 05:44:03 UTC
Created attachment 185140 [details]
tablesplit1.odt (see STEPS TO REPRODUCE)

Sometimes tables are wrongly split across a page break and/or wrap into the wrong column on the next page, and the splitting behavior is not stable over save & reload.

Attached are a couple of test case .odt files.  Each of them started as a single page containing a SECTION with two columns (so the text before the section is single-column).   

The 2-column section contains several Tables (all but the first copy-pasted).  

=== CASE 1 STEPS TO REPRODUCE ===

1. Load attached tablesplit1.odt

Notice that the last table ("table #6") is split across the page break, but the split-off portion appears in the SECOND column of the next page, not the first column.   That is, the split portion of table #6 appears "after" table #7 (which is in the first column of the second page).

2. Put cursor in table #6
   Table->Properties->Text Flow

Notice that "Allow table to split across pages and columns" is NOT checked.

RESULTS: Table #6 wrongly split with the split-off portion landing in the 2nd column of the next page, i.e. "after" Table #7

EXPECTED RESULTS: Table #6 should have forced a skip to the next page because there is not enough room for it in the remaining space on the first page.

=== CASE 2 DESCRIPTION ===

Please see "exploded_screenshot.png" where the last table is split into many pieces on several pages.   I got this after some sequence of inserts and pasting of copies of the table which I can't reproduce.

After I did Save and then Reload, the rendering changed so that it was similar to CASE 1 above.  Please see "after_save_reload.png".   Something about this bug  makes rendering unstable across save & reload.
Comment 1 Jim Avera 2023-02-06 05:44:40 UTC
Created attachment 185141 [details]
exploded_screenshot.png
Comment 2 Jim Avera 2023-02-06 05:46:24 UTC
Created attachment 185142 [details]
after_save_reload.png
Comment 3 Jim Avera 2023-02-06 05:55:28 UTC
Unfortunately, the unstable rendering problem made "tablesplit1.odt" no longer show exactly the problem described in the original report.    

Instead, after reloading tablesplit1.odt, Table #6 is not split but table #7 is split across columns within the second page.

No splitting of any kind should occur because none of the table have splitting enabled in their Properties.
Comment 4 Jim Avera 2023-02-06 05:57:01 UTC
Created attachment 185143 [details]
tablesplit1_screenshot.png
Comment 5 Telesto 2023-02-06 07:13:57 UTC
(In reply to Jim Avera from comment #0)
> === CASE 2 DESCRIPTION ===
> 
> Please see "exploded_screenshot.png" where the last table is split into many
> pieces on several pages.   I got this after some sequence of inserts and
> pasting of copies of the table which I can't reproduce.
> 
> After I did Save and then Reload, the rendering changed so that it was
> similar to CASE 1 above.  Please see "after_save_reload.png".   Something
> about this bug  makes rendering unstable across save & reload.

Steps to reproduce this/similar case
1. Open attachment 185140 [details]
2. Go to multi page view
3. Cursor in Table 5, bottom row
4. Press add row

Already reported somewhere, I think. However still a nice and clean testcase, though
Comment 6 Buovjaga 2024-09-24 11:47:54 UTC
(In reply to Telesto from comment #5)
> (In reply to Jim Avera from comment #0)
> > === CASE 2 DESCRIPTION ===
> > 
> > Please see "exploded_screenshot.png" where the last table is split into many
> > pieces on several pages.   I got this after some sequence of inserts and
> > pasting of copies of the table which I can't reproduce.
> > 
> > After I did Save and then Reload, the rendering changed so that it was
> > similar to CASE 1 above.  Please see "after_save_reload.png".   Something
> > about this bug  makes rendering unstable across save & reload.
> 
> Steps to reproduce this/similar case
> 1. Open attachment 185140 [details]
> 2. Go to multi page view
> 3. Cursor in Table 5, bottom row
> 4. Press add row
> 
> Already reported somewhere, I think. However still a nice and clean
> testcase, though

No need to be in multi page view. Already in 3.5.

Arch Linux 64-bit
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4787fd4fc86230893a6da309f45964116b3a67df
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 24 September 2024