Bug 74036 - EDITING: Text in vertically-spanned table cells which goes across page boundaries is not positioned in the center of the cell
Summary: EDITING: Text in vertically-spanned table cells which goes across page bounda...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-25 04:00 UTC by Jim Avera
Modified: 2015-07-18 23:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
.odt file with demo of the bug (15.68 KB, application/vnd.oasis.opendocument.text)
2014-01-25 04:00 UTC, Jim Avera
Details
PDF - which shows mis-placement of characters (55.95 KB, application/pdf)
2014-01-25 04:01 UTC, Jim Avera
Details
Screen shot showing mis-rendering at page boundary (90.10 KB, image/png)
2014-01-25 04:01 UTC, Jim Avera
Details
Screen shot showing correct rendering all on one page (88.18 KB, image/png)
2014-01-25 04:02 UTC, Jim Avera
Details
more merge issues (69.65 KB, image/png)
2014-07-11 15:13 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2014-01-25 04:00:29 UTC
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.
Comment 1 Jim Avera 2014-01-25 04:01:07 UTC
Created attachment 92751 [details]
PDF - which shows mis-placement of characters
Comment 2 Jim Avera 2014-01-25 04:01:50 UTC
Created attachment 92752 [details]
Screen shot showing mis-rendering at page boundary
Comment 3 Jim Avera 2014-01-25 04:02:20 UTC
Created attachment 92753 [details]
Screen shot showing correct rendering all on one page
Comment 4 Jim Avera 2014-01-25 04:41:33 UTC
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.
Comment 5 Yousuf Philips (jay) (retired) 2014-07-11 15:12:46 UTC
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.
Comment 6 Yousuf Philips (jay) (retired) 2014-07-11 15:13:27 UTC
Created attachment 102623 [details]
more merge issues
Comment 7 QA Administrators 2015-07-18 17:44:22 UTC
** 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
Comment 8 Jim Avera 2015-07-18 23:11:56 UTC
It seems to be fixed in 5.0.0.0.beta3

Setting Status to RESOLVED - WFM