CONFIRMED on LO 4.2.0.0.beta2 + Ubuntu 12.04.3

(In reply to comment #0)
> Created attachment 90382 [details]
> A file that changes its own number of pages :-)
> 
> I have an .odt document with a long table with ~200 rows 2 columns, one in
> Hebrew and one in English. 
> 
> When I finished the document it was 41 pages long, but when I close and
> re-opened it it becomes 43 pages long.

Interesting... perhaps there's something that we represent differently when we write-out the document to disk.

> One row (not always the same one, but
> usually the same one) is driven to the next page even though it clearly has
> enough space on the current page. The row above it does not change its size
> - it simply has plenty of white space below it. When I open the file I can
> see in the bottom bar the number "41" changing into "43" half a second after
> openning the file.

When I first open this document the Status Bar displays "Page 0 / 42", however if I wait for an extra 10 seconds or so, it updates to "Page 0 / 43".

> I can use the mouse to "squeeze" the height of the row above the driven row,
> and thus making the document 41 pages again,

Confirmed.

> but when I save, close and open
> the document, it re-calculates the sizes and becomes 43-pages long once
> again.

Confirmed -- I can drop the page count down to 41 or 42, depending upon how I tweak the bottom of those rows, but after every save and reload, the page count pops back to '43'.

> 
> If I do not correct manually the 43-long document, add a character, save and
> close it, it becomes 42 pages long the next time I open it...
> 
> Te "evil split" usually occurs below the stanza which says:
> 
> "'Had I no eyes but ears, my ears would love
> That inward beauty and invisible;
> Or were I deaf, thy outward parts would move
> Each part in me that were but sensible:
> Though neither eyes nor ears, to hear nor see,
> Yet should I be in love by touching thee.
> ----

In my case, the break was occurring just *before* "Had I no eyes".

Status -> NEW

Just to mention that this starts at row 75..
(Somtimes I have strange wrapping probs with graphics at the page bottom too.. Must be un related ;))

@Yotam: any idea in which version this previously was OK (if any?)
thanks,
Cor

Sorry, that document is old but only when it reached its full size, several months ago, it started acting weirdly. I don't know if it works well with former versions.

I strongly suspect that this bug is a duplicate of bug 63737.  Both utilize tables and complain of paging that changes.

(In reply to comment #0)
> When I finished the document it was 41 pages long, but when I close and
> re-opened it it becomes 43 pages long. ... When I open the file I can
> see in the bottom bar the number "41" changing into "43" half a second after
> openning the file.

Opening the ODT under GNU/Linux using:

- v3.3.4.1 OOO330m19 Build: 401
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
- v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16

These are the number of pages initially displayed in the status bar (Init); what it updates to after a few seconds (Upd1); and what it updates to after manually paging through the entire document (Upd2):

v    Init  Upd1  Upd2
-    ----  ----  ----
3.3  42    43    41
3.4  42    43    41
3.5  42    43    41
3.6  42    43    43
4.0  42    43    43
4.1  42    43    43
4.2  42    43    43
4.3  42    43    43
4.4  42    43    43

The behaviour at least appears to be relatively consistent for v3.3-3.5 and v3.6-4.4. As a result of this version set to 3.6.7.2. The best way to avoid rendering issues such as these is to keep these aspects of the formatting an even multiple of (or readily relatable to) each other:

- Font size (currently 12 pt).
- Line height (currently Single, thus ~14.1 pt).
- Line spacing/leading (currently 0 pt).
- Table cell spacing (currently 2.9/2.9/2.9/11.3 pt).

This is one reason why the 12 pt font size has such currency: it is convenient to both multiply and divide. As a workaround, perhaps try setting the line height to a fixed value (16 pt e.g., 1 1/3 the point size) and the table cell spacing top / bottom to 4 pt or 6 pt. This may give a more stable result.

Thank you, Owen, but I'm not sure I understand. How can I change all these values to be multiples of each other (in centimeters? inches? pixels?) and still have a readable, decently formatted document?
I hope someone finds a way to fix this soon - this probably affects all documents which contain long tables and have custom spacing here or there.

Created attachment 107032 [details]
ODT restyled copy of the original now displaying fixed rendering

(In reply to comment #11)
> Thank you, Owen, but I'm not sure I understand. How can I change all these
> values to be multiples of each other (in centimeters? inches? pixels?) and
> still have a readable, decently formatted document?

It is best to try and use points as that is what fonts are measured in. Try the attached version. These are the changes I have made:

- Default Style paragraph style: Line height Fixed at 16 pt. This changed all other paragraph styles to same setting. Usually heading styles would require some re-adjustment due to using a larger font size, but in this instance the headings are relatively small and can be left as-is, with a single line of leading (16 pt) i.e., refer next two points.
- Heading 1 paragraph style: Spacing above 16 pt; Spacing below 0 pt.
- Heading 2 paragraph style: as per Heading 1.
- Text Body paragraph style: Spacing below 0 pt.
- Table border spacing to contents (Venus and Phoenix table): left/right/top/bottom 4 pt.
- Default Style page style: Margin top 48 pt; Margin bottom 72 pt; Footer spacing/height 16 pt. This is important because a US Letter page is 792 pt in height and the text block needs to be an exact multiple of the standard paragraph text line height i.e., 792 - 48 - 72 = 672 / 16 (line height) = 42 - 2 (spacing to footer and footer height now equal 2 lines) = 40 line text block.
- First Page page style: Margin top 48 pt; Margin bottom 72 pt.

Note that the text near the beginning of each table is occasionally set in varying point size e.g., "Venus and Adonis". There is however enough space (following blank line) to cater for this variability.

Opening this edited copy under the same versions of LO listed in comment 10 now results in a static 42 pages (on open; after a few seconds; and after paging through the entire document) under all versions. Many rendering-related bugs have a similar underlying cause. Laying out documents is best done in terms of a base unit, which is usually the line height of the Default Style / Text Body paragraph style (which in turn works best as a factor of the font size of the style). Hopefully this helps.

Wow! Thank you very much, Owen, for all your help and for your thorough explanations. 
The workaround seems to work well indeed. 
I hope that this bug is resolved one way or the other - whether by making writer smart enough to deal with all sizes and values in a consistent manner, or by limiting the extent in which the user can change its values and sizes.

Created attachment 107049 [details]
Still affected with the issue

It seems that I was too quick to get excited. I changed my current version according to the instructions (excluding the page style, as I am not concerned with printing and these changes make the document look weird) plus one page break, and the document starts now with 42 pages, then happily jumps to 46. Maybe I missed something...

(In reply to comment #14)
> I changed my current version according to the instructions (excluding the page 
> style, as I am not concerned with printing and these changes make the document 
> look weird) 

As I indicated, the margins are key. Adjust them as required 48/72 or 50/70 or 55/65 etc. So long as the top+bottom values total 120 pt (or 120+16 or 120+32 etc.). This keeps the text block of the page a consistent number of lines. Also the spacing to footer for both page styles has not been set as I indicated and this too influences the text block. Finally, the first and last tables do not have the space to contents set as I indicated.

Thanks a lot! Apparently I did not know where to look for page margin settings (this is not exactly trivial, as I do not use an English UI). Now the poor document is resting in peace at last.
Maybe the option to set them to anything else than 120 pt put together should be blocked by libreoffice, as it can't handle it too well.

Created attachment 107083 [details]
43 becomes 48

Maybe I missed something, but the document refuses to rest... Now 43 pages become 48.

My thinking is that, aside from functions such as RANDOM(), and given the same hardware, OS, libraries, and build of LibreOffice, the layout of a particular ODT is roughly deterministic. Or it should be.

When we tweak the parameters of this (or other) documents in LibreOffice, my guess is that we're not able to completely capture all of those modifications *exactly* and store them into the ODF file format. Maybe there are some floating point numbers rounded off or etc. When the the file is reopened on the same machine with the same exact copy of LibreOffice, we don't have the same set of inputs to the function, and so our output is different.

So the important questions are: 
- What information are we not storing accurately?
- Is there any information we're not able to store?

(In reply to comment #17)
> Maybe I missed something, but the document refuses to rest... Now 43 pages
> become 48.

Same problems I mentioned last time, with the exception of the page margins. The font size has been increased (from 10 pt) to 12 pt, thus the length (once calculated) is now 48 pages. This has to be determined by the rendering engine (by reading through the entire content) as it is not stored in the document. This is normal, as the following hopefully explains.

(In reply to comment #18)
> My thinking is that, ... the layout of a particular ODT is roughly 
> deterministic. Or it should be.

I am not one for analogies, but here goes ... There is a difference in computational performance when reading from disk/memory in random-sized chunks vs reading in consistent block sizes that match the handling ability of the operating system. As is always the case with computers, knowing the magic numbers usually helps with performance (and sometimes stability). On-screen rendering is the same, it is just that the magic numbers are the derivative of 400 years of typesetting.

Unfortunately, that history is now largely discarded/forgotten, as evidenced by the Design team's recent reworking of the default Writer template. Proportional measures, mismatched sizings, keep-with-next/orphan/widow and similar auto- settings, as well as many other subtle/hidden settings such as table spacing, all come at a cost. In simple terms, the rendering engine has more work to do, particularly if direct formatting is used in an ad hoc manner. This is one reason why I would never use the default settings (template) provided with LO, in situations where layout is important.

By contrast, a single page style with *exactly* calculated / matching margins, head/foot area, footnotes, text lines, table spacing, et al. is much simpler for the rendering engine to handle and more likely to produce a consistent result as there is minimal variance. The stability in the example I provided was not by chance. We could create a template using these types of figures, but the problem is it varies according to the number of required heading levels i.e., in order to know how far up the point scale the headings go. This is the nature of typesetting.

I have seen most versions of MS Word behave in the same manner as reported here (for the same reasons). I honestly do not believe there is any effective way around the problem reported here, other than what I have tried (in limited manner) to illustrate.

> (In reply to comment #18)
> > My thinking is that, ... the layout of a particular ODT is roughly 
> > deterministic. Or it should be.
> 
> I am not one for analogies, but here goes ... There is a difference in
> computational performance when reading from disk/memory in random-sized
> chunks vs reading in consistent block sizes that match the handling ability
> of the operating system.

Okay, so that just sounds like a potential slow-down.

> In simple terms, the rendering engine has
> more work to do, particularly if direct formatting is used in an ad hoc
> manner. This is one reason why I would never use the default settings
> (template) provided with LO, in situations where layout is important.

That seems pretty reasonable in terms of cross-platform or even between-machine compatibility, but I'm talking about a single, unchanging stack of hardware and software.

> By contrast, a single page style with *exactly* calculated / matching
> margins, head/foot area, footnotes, text lines, table spacing, et al. is
> much simpler for the rendering engine to handle and more likely to produce a
> consistent result as there is minimal variance.

Those sound like good best practices, but I think that my previous claim stands: On a single computer using a single copy of LibreOffice, I wouldn't expect the # of pages to change. If we're losing some data due to round-off, then let's a make a note of it and possibly fix it. If there's actually a non-deterministic function involved in the layout, let's document it and (maybe?) fix it.

I agree with qubit, of course. It seems that at this point, the "good practice" became so complicated that I couldn't follow it for the life of me, no matter how much I tried.

But I want to draw the attention to another point here. The problem, for me, is this: I save a document in a good condition, with all the table rows tucked in neatly, and when I open it, libreoffice adds unneeded breaks. You can see for yourself that there is plenty of space for rows left in each page of the "long" document, and that you can correct this if you manually "squeeze" the lower bborder of the first affected row with the mouse. So as I see it, it is a problem of the automatic table spreading routine, which fails in some cases to see that there is more than enough space for the last row in a page.

I have gone back and re-read the entire report and re-examined all the attachments, because I do not mean to be overbearing. I am trying to help, so I apologise if I have come across as otherwise.

(In reply to comment #20)
> Those sound like good best practices, 

Yes. It is difficult to be clear(er) because typesetting a document is not as simple as many people make out. There are a lot of variables. I guess my effort (comment 12) is merely indicative that Writer looks more favourably upon certain settings for some reason and that it has long been this way (Word too, as I indicated). Large text tables are especially problematic and that is likely at the heart of this issue. For some reason text table handling always seems more problematic.

> I think that my previous claim stands: On a single computer using a single
> copy of LibreOffice, I wouldn't expect the # of pages to change. 

I understand the deterministic aspect. I was focussing on the 42 -> 43 pages (when the document as displayed is 43 page in length). My overall point was that the rendering engine (in this sense) is calculating the result correctly. I admit this fails to consider this aspect:

(In reply to comment #0)
> One row (not always the same one, but usually the same one) is driven to the 
> next page even though it clearly has enough space on the current page. 

... which Yotam has repeated in comment 21. Here is a basic examination of pages containing enough space at the bottom to include the first row on the next page (i.e., unnecessary bumping), based on attachment 90382 [details]:

- Page 15-22 all appear to have enough space at the bottom to contain an additional row.
- The result of this is that page 39 contains only a single row i.e., is an unnecessary additional page.
- In v3.3-3.5 placing the cursor on page 15 automatically re-adjusts (drags back) all the pushed rows, thus removing the single row from page 39 (in fact it drags back enough rows to remove both 38 and 39).
- In v3.6+ placing the cursor on page 15 has no effect. 

I would surmise from this that text table handling has been altered (v3.6) to have a more fixed/static approach. This does not however explain the incorrect rendering calculation beginning at the foot of page 15.

(In reply to comment #6)
> Just to mention that this starts at row 75.

Looking at the status bar I see row 69 (of 201) being the final row at the foot of page 15 (with row 70 at the head of page 16). 

> If we're losing some data due to round-off, then let's a make a note of it 
> and possibly fix it. If there's actually a non-deterministic function 
> involved in the layout, let's document it and (maybe?) fix it.

Agreed. Here are some calculations based on page 15. Top page margin 57 pt. Cell spacing is set to 2.9 pt (top) and 11.3 pt (bottom), thus 14.2 pt per cell. There are 6 lines of text per cell with 14 pt (Single) line height, so 84 pt, or 98.2 pt per cell. On page 15 there are 5 rows totalling 491 pt. Thus 57 + 491 = 548 pt from top of the page to the bottom of row 69 on page 15. 

If I draw a line on page 15, anchor it to page, position it 0 pt from page top, make it 5 pt thick to see clearly and 548 pt in length, it extends beyond the bottom of row 69. Even at 0 pt from page top it /appears/ to sit about 1 pt beneath the page edge, but this still does not account for the ~5 pt or so it extends below row 69. Hmmm. ~5 pt ... 5 rows. Perhaps there is an extra 1 pt in each table row? Is this the rounding error we are looking for?

Best wishes Yotam in getting this issue addressed.

This bug still exists on LibreOffice 5.0.2.2, on Ubuntu 15.10.

This bug still exists in version 5.2.1.2. Windows 8.1

I have a long table with 11 columns and 39 pages. When I reopen it, it jumps to 79 pages !
Before that it used to add a few extra breaks here and there adding only a few pages, but now, it adds 40 pages with an identical shortened layout, as if all the pages from a certain point were reduced in height.
The scale on the side is not reduced in height
If I suppress a space at the end of the last word of the column where the unneeded breaks start, it jumps back to 39 ! 
One saved and reopened, it jumps backs to 79 pages again after 2-3 seconds.

I have not yet tried to modify the layout as suggested above, I'll try this and report here.

Note that if I save the table with FreeOffice's TextMaker, it stays at 39 pages when I reopen it. So this is a work around.

This bug still exists in version 5.4.1.2 on Windows 10.

I can't repr. with the attached file, but I'm encountering a similar table-rendering issue in both LOO and NOO on the Mac. If this is the same issue, that suggests this was inherited from OO and this affects MacOS as well as Windows.

Changing table formatting can fix individual tables in OO, but it seems awfully ad-hoc:

https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=40591

I have multiple tables in my document, rather than one long table. If I copy one of the affected tables to a test file, it displays properly, but in the main file, the second page has only a couple rows before splitting to the third, the third page ha only a couple rows before splitting to the fourth, etc.

Typing enter and delete before one of the breaks *temprarily* removes the break, but it re-opens with the same break.

If I use the navigator to check each table, it keeps freezing and renumbering them. Assuming it isn't actually moving them, which would be bad.

With current LO, test master 6.5+, first shown is 42 pages and shortly after 41. If resaved and reopened, number stays 41.
I saw also improvements on repagination in other bugs.
I didn't read the whole bug nor looked content. 
Unless reverse bibisect is done, I close as WFM.