Created attachment 182843 [details] Test-table-file Hi, Actual behaviour: When a table spans across multiple pages (especially with bigger font) the way it is split in some parts of the text is very page consuming: only part of the cell is shown at the top of the page on each page (from page 184 in the attached file, for example) [In my documents, the text is split into a table where I have a source language on the left and a target language on the right] The attached document had to be changed for privacy reasons. Desired behaviour: it should split the cell in a more efficient way, filling the space available in the page. Reproduce: Follow the steps above. Version: 7.4.1.2 / LibreOffice Community CPU threads: 8; OS: Mac OS X 12.6; UI render: default; VCL: osx Locale: it-IT (it_IT.UTF-8); UI: en-US Calc: threaded
With 7.4.0 I opened 267 pages which then went to 216 pages and later to . With 7.5+ it was 322 pages but next open was 380 pages. It's an issue known as "pagination" but this sample shows it awfully. Reproduced 7.5+ at 1st (slow) open for a split at page 184 of 322 pages. I think it already in Bugzilla
With 7.4.0 I opened 267 pages which then went to 216 pages and later to 274 pages and to 236 pages and to 207... I guess it just changes With 7.5+ it was 322 pages but next open was 380 pages. It's an issue known as "pagination" but this sample shows it awfully, especially it's just text in table and 165 footnotes and some comments. With previous problem, this bug issue ot "page 184" is not consistent so rather changed text or bookmark should be a reference. But I think it's also a known problem of reflow. Note: ODT is slow to open, there's at least bug 130822 for footnotes. This should be tested and searched more.
Retested with Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Steps: 1. Open attachment 182843 [details] => statusbar shows 54 pages (O.K.) 2. Wait some tiime -> statusbar shows 335 pages with a lot of empty space Actual result Bad pagination Esxpected reslt optimal pagination (see for example p. 318-335) I've found some related bugs, but not a duplicate => NEW