Description: 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 Actual Results: The roundtrip does not fully preserve the document content. The table height is lost. Expected Results: The roundtrip should preserve the table height. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 149967 [details] Test document
I can't reproduce it in Version: 6.3.0.0.alpha0+ 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 Calc: threaded 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 6.2.4.1 and 6.1.x (all). I haven't tested yet with the master daily builds. For what concerns 6.2.4.1, my install is as follows: Version: 6.2.4.1 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 Calc: threaded 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: 6.3.0.0.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 Calc: threaded but not in Version 4.1.0.0.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 commit 5e9335e3e63b7f88dd40f4d2bc530aac8141d205 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 22:35:24 2015 +0800 source-hash-9746dc9ad62e7f3a39961733f2ac204e90289034 commit 9746dc9ad62e7f3a39961733f2ac204e90289034 Author: Markus Mohrhard <markus.mohrhard@collabora.co.uk> AuthorDate: Wed Jul 2 22:58:56 2014 +0200 Commit: Markus Mohrhard <markus.mohrhard@collabora.co.uk> CommitDate: Wed Jul 2 23:03:09 2014 +0200 fix ODF validation errors Introduced by 7d9bb549d498d6beed2c4050c402d09643febdfa
Quite a bit of change in 7.1. For a while it loaded with a smaller size (but then that commit 7dc234fa57ca409d0db131c93abea738014b5e1f was reverted). This now depends on bug 139511 being fixed first, because the ability to shrink the table has been lost since around 7.0.4.
Dear Callegar, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to raal from comment #8) > I'm not sure if it's really regression. Bibisect with bibisect-44max. > 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. This "good" bibisect 4.4 state is what I see again in development 24.8. Probably this bug report can be closed. I'm guessing that the reason the table can be reduced in size at all might have something to do with font substitution - I don't have the font installed that the table contents are using. If I change to an installed font, reduce the table to as small as possible, and then round-trip height is virtually identical. In any case, the difference between minimum cell height during import compared to during table UI resize is rather minimal in the example document.
The bug is definitely still there in 24.2.0.3. Please do not close. What is happening is not due to font substitution, since I do have the correct fonts. Even if the change between 72 and 62 mm may seem minor, it can break formatting. If you do not change your system fonts or if you save the fonts with the document, when you reopen the document it should be "exactly" as when it was saved, not just similar. Unfortunately, in the current situation the only reliable way to have a table that "stays" at its correct size is to import it as an image, which unfortunately breaks the possibility to edit it afterwords. Reasonable workaround is to use the TeXMath extension to build the table as an image in a programmatic (and thus editable) way. However this is probably not something every user can do.