LibO Impress and Draw include an insert table function. Unfortunately, table formatting does not seem to be always preserved during a save/load roundtrip.
The issue is certainly present in LibO 6.0.x, 6.1.x, 6.2.x and probably also in previous versions (which I cannot test).
I have managed distilling a reproducible test case and a document is attached to this report. Please, follow the instructions in "steps to reproduce" to work with it.
Steps to Reproduce:
1. Open the test document, note that there is a table in it. Select the table and right click to get the object position and size, see that the height is 72.29 mm
2. Click on the bottom handle of the table and kindly push it up. See that the table gets reduced in its height. Reduce the table height as much as possible.
3. Check the table height again. Now it should be 62.39mm
4. Save the document, close LibO
5. Reopen LibO and reopen the document, check the table height. The table height is back to 72.29mm
The roundtrip does not fully preserve the document content. The table height is lost.
The roundtrip should preserve the table height.
User Profile Reset: No
[Information automatically included from LibreOffice]
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Created attachment 149967 [details]
I can't reproduce it in
Build ID: 64faea31f7d05e46fe5c91f87381ec7abae90174
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Created attachment 151268 [details]
Situation after opening the test document
Created attachment 151269 [details]
Situation after editing the test document that cannot be preserved in roundtrip
The issue is certainly still present in 184.108.40.206 and 6.1.x (all). I haven't tested yet with the master daily builds.
For what concerns 220.127.116.11, my install is as follows:
Build ID: 170a9c04e0ad25cd937fc7a913bb06bf8c75c11d
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: kde5;
Locale: it-IT (en_US.utf8); UI-Language: en-US
I have added two screenshots to better detail the problem.
Snapshot1 (situation after opening the test document) is what you get at point 1 in my "reproduction recipe". Note how the bottom of the table is at about 1.5 cm from the bottom of the page.
Snapshot2 (situation after editing the test document that cannot be preserved in roundtrip) is what you get at points 2 and 3. Note that the bottom of the table now is at about 2.5 cm from the bottom of the page.
If you save and reload the document, on my system you go back to snapshot 1.
Where is the bottom of the table at points 1, 2-3, and 5 on your test system?
[Automated Action] NeedInfo-To-Unconfirmed
Confirm with Version: 18.104.22.168.alpha0+
Build ID: 630db80d17616d635cf2e5f1d5a0852428b794a3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11;
Locale: cs-CZ (cs_CZ.UTF-8); UI-Language: en-US
but not in Version 22.214.171.124.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
I'm not sure if it's really regression. Bibisect with bibisect-44max. In "bad" version is table's height 6,24 cm, reduced height 5,76 cm and after save and relod it's 5,93 cm. In "good" version is table's height 7,23 cm, reduced height 7,06 cm and after save and relod it's 7,23 cm again.
5e9335e3e63b7f88dd40f4d2bc530aac8141d205 is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Sat Mar 14 22:35:24 2015 +0800
Author: Markus Mohrhard <firstname.lastname@example.org>
AuthorDate: Wed Jul 2 22:58:56 2014 +0200
Commit: Markus Mohrhard <email@example.com>
CommitDate: Wed Jul 2 23:03:09 2014 +0200
fix ODF validation errors
Introduced by 7d9bb549d498d6beed2c4050c402d09643febdfa