https://bugs.freedesktop.org/show_bug.cgi?id=72424
--- Comment #22 from Owen Genat <[email protected]> --- 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: - 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. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
