Created attachment 195499 [details] Cell contents ofsset downwards and clipped in last page of table When cells are merged in a column (vertical merge), cell contents overflows a page and vertical alignment is other than Top, text chunk in the last page segment for the oversize merged cell is shifted downwards and clipped at cell bottom boundary. This error condition is particularly persistent: changing vertical alignment in Table Properties has no effect until save-close-reopen. It occurs only in the last segment needed to host cell contents. Attached document has been created with A6 pages so that the problem happens with relatively small text amount. It was detected in an A4 document. As shown text in merge cell is spread over 3 pages. Pages 1 and 2 have full-page text quantity and text displays apparently as expected (not sure about exact centering -- in a full-page cell, there should not be a big difference). Remaining text is less than 1-page high. Cell height is apparently correctly computed but text is rendered shifted downwards and clipped to the limit of the cell. In the sample document (vertical alignment requested), the faulty text faces an empty cell. If text is added is this column until it reaches the badly aligned cell, text position will change but never for center (space above and below are not equal). And when facing additional text overflows the page, previously-faulty text jumps to top despite vertical alignment. I see then two bugs: - bad downwards offset with clipping - no application of requested vertical alignment when there is ample room in cell While working on this bug, trying to workaround/fix it, I noticed that there is an inconsistency in ODF XML encoding of merged cells: - Horizontal merge (within a row): "now-unreachable" cell is described by <table:covered-table-cell/> - Vertical merge (within a column): "unreachable" cell is described by <table:covered-table-cell table:style-name="Table1.A3"/>, i.e. it contains a reference to a table style. This reference is pointless because the "unreachable" cell is an empty dummy one. I experimented first on a real case where removing the style reference initially fixed the offset and clipping. Unfortunately this fix was transient. I am then not sure it is part of the problem but it is certainly worth it to remove the inconsistency. This bug may be a duplicate of bug 70745, where text rotation (90°) is involved. Certainly a duplicate of bug 137612, bug 156966 and bug 159029. Which is the "leading" bug so that I cc: on it? PS: also occurs in 7.6.7.2
I think this is a duplicate, please if you are not agreed, reopen it. *** This bug has been marked as a duplicate of bug 159029 ***