Created attachment 92750 [details] .odt file with demo of the bug When a table contains vertically-spanned cells which are divided at a page boundary, the cell boundaries are sometimes rendered in the wrong position, causing text to be lost or truncated. The bug seems sensitive to having adjacent rows of different heights (e.g. containing text of different font size). Just to be clear, the expected behavior is that when a vertically-spanned cell must be divided at a page boundary, each piece should be tall enough to render the text it contains (currently chars are rendered outside or overlapping the "subcell" (the piece after a page break) and so are not fully visible. Please view the attached screen shots. I'll also attach a small demo .odt file, and a pdf from File->Export to PDF which makes it clear the characters are rendered partially-outside the cell boundary.
Created attachment 92751 [details] PDF - which shows mis-placement of characters
Created attachment 92752 [details] Screen shot showing mis-rendering at page boundary
Created attachment 92753 [details] Screen shot showing correct rendering all on one page
This comment discusses possible fixes, at a 50,000-foot level. The easiest fix might be to just refuse to split cells (including vertically-spanned cells) across page boundaries; tables would only be split where cell tops or bottoms aligned horizontally all the way across the table. If there was no such spot, and the table didn't fit on one page, then it would render wrong (i.e. that case would not be supported). I would be okay with such a restriction because it's a rare condition, but others might not be. The ideal solution would include looking for a spot where the bottoms of individual text lines inside cells align all the way across the table, and split all the cells at that location. Bottoms would not need to align where there is vertical white space, i.e. a large vertical skip can be truncated at the page boundary. IMO this would give the best results. However it is impossible in the general case because text rows might never align near page boundaries. Therefore cell appearance somtimes MUST be distored to split a table. A good compromise might be: In all cells which would fall off the end (if not split), find the lowest-positioned text line or object which does *not* overlap the page bottom; then insert "phantom" vertical space after those points in the respective cells so as to push the next line (or sub-table, image, etc.) completely past the line of demarcation (i.e. onto the next page). AFter inserting those phantom vertical spaces, the "ideal" solution above becomes possible. Note that the amount needed phantom vertical space might not be a multiple of the line spacing in any given cell. It might work to insert a line-break wrapped in a text span which sets the exact font size needed. By "phantom" I mean objects which are not really (or not permanently) in the document, but conceptually introduced to facilitate formatting.
Dear Jim, Thank you for submitting the bug. I can confirm that the bug is available in 3.3.0, 4.2.5 and master. Also noticed that if i typed some extra words in B3 across 3 lines and the merge it with B2, things get even worse in A1.
Created attachment 102623 [details] more merge issues
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
It seems to be fixed in 5.0.0.0.beta3 Setting Status to RESOLVED - WFM