Bug 82452 - Table with row height set to "at least" inside another table truncated if it does not fit on a single page
Summary: Table with row height set to "at least" inside another table truncated if it ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-11 08:16 UTC by merike
Modified: 2016-05-21 05:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example file (58.50 KB, application/msword)
2014-08-11 08:16 UTC, merike
Details
pdf (25.72 KB, application/pdf)
2014-08-11 08:17 UTC, merike
Details
example for comment 4 (11.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-18 07:18 UTC, merike
Details

Note You need to log in before you can comment on or make changes to this bug.
Description merike 2014-08-11 08:16:19 UTC
Created attachment 104415 [details]
example file

Similarly to bug 67975 if there's a table within another table that doesn't fit fully on a page it gets truncated and some content is impossible to see. See attached file for example and pdf for how it's supposed to look like.

This reproduces in 4.3.1.1 but that is unavailable for version field...
Comment 1 merike 2014-08-11 08:17:56 UTC
Created attachment 104416 [details]
pdf
Comment 2 ign_christian 2014-08-11 15:58:16 UTC
Hi.. Could you give simple steps to reproduce that problem from scratch?
Comment 3 merike 2014-08-12 12:47:26 UTC
Not right now. The example document was not created by me, I only minimized it to be smaller while still containing the bug.

I can try to figure out with a new document what exactly causes this but that'll take time. If I create a similar document and compare them in docx format which is easiest because then it's text-based then there are quite some differences initially.
Comment 4 merike 2014-08-18 07:18:02 UTC
Did some more testing and this should repro in new document:
1. insert 1x1 table
2. insert 1x8 table into it
3. enter single numbers into these 8 cells (just for better visibility of what's happening)
4. set inner table row height to "at least" 3cm (on a A4 page with default margins)

After doing that in Word cells 7 and 8 display on second page. In Writer half of cell 7 displays on first page, cells 8, 9 and 10 are missing and second page appears empty. Can someone confirm?
Comment 5 merike 2014-08-18 07:18:59 UTC
Created attachment 104793 [details]
example for comment 4
Comment 6 Buovjaga 2014-11-12 12:05:32 UTC
(In reply to merike from comment #5)
> Created attachment 104793 [details]
> example for comment 4

I can confirm that it looks like your description when opened in Writer.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 1c526c9ddda5d52f7a4db5655a4ec60b8c62835c
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-11_23:20:41
Comment 7 merike 2014-11-30 18:16:01 UTC
Why severity=minor? I'd argue that if you're sent such a document and you're unable to see some of its contents it's data loss from user's point of view, despite the information being present in the file itself.
Comment 8 Yousuf Philips (jay) (retired) 2014-11-30 21:26:34 UTC
Hi merike,

I'm setting it back to normal. Though it does look truncated in print layout view, it looks fine in web layout view.

I noticed that if i was in web layout view and deleted the table after 'Text before first table' (right-click > column > delete) and then switched to print layout view and pressed undo, the document would look as it should.

Version: 4.5.0.0.alpha0+
Build ID: 8bc56801af0540c0496c1f8ddd335578a8791017
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-11-28_23:01:06
Comment 9 Yousuf Philips (jay) (retired) 2015-08-07 19:53:02 UTC
Attachment 117718 [details] seems to be another candidate document for this problem, tables inside a table across multiple pages.

Version: 5.1.0.0.alpha1+
Build ID: 902255645328efde34ddf62227c8278e8dd61ff0
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-07-30_05:23:12
Locale: en-US (en_US.UTF-8)
Comment 10 Aron Budea 2016-05-09 21:33:12 UTC
Looks okay in build from master branch, so this will hopefully be fixed in 5.2.

Version: 5.2.0.0.alpha1+
Build ID: 039b75d6cdc26dcce03e37c67115405e6f2a8ebe
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: hu-HU (hu_HU)
Comment 11 Aron Budea 2016-05-12 11:02:23 UTC
In fact, bug is gone with release candidate 5.1.3.2 (was still reproducible in 5.1.2.2). Please use that, or wait until the release of 5.1.3.
Comment 12 Yousuf Philips (jay) (retired) 2016-05-19 11:09:15 UTC
Fixed in 5.0 as well.

Version: 5.0.6.3
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: en-US (en_US.UTF-8)

@raal: can you bibisect when this was fixed?
Comment 13 raal 2016-05-19 11:31:36 UTC
(In reply to Yousuf (Jay) Philips from comment #12)
> Fixed in 5.0 as well.
> 
> Version: 5.0.6.3
> Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
> Locale: en-US (en_US.UTF-8)
> 
> @raal: can you bibisect when this was fixed?

Hi Jay, I can, but why? "Fixed in 5.0 as well." + "bug is gone with release candidate 5.1.3.2" + "Looks okay in build from master branch"
Comment 14 Yousuf Philips (jay) (retired) 2016-05-21 05:47:12 UTC
(In reply to raal from comment #13)
> Hi Jay, I can, but why? "Fixed in 5.0 as well." + "bug is gone with release
> candidate 5.1.3.2" + "Looks okay in build from master branch"

Hi raal, just curious if it got fixed through another bug report or whether it was a fix pushed in independently by a dev.