Bug 124077 - Broken roundtrip (save/load) for impress/draw document including tables
Summary: Broken roundtrip (save/load) for impress/draw document including tables
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on: 139511
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2019-03-14 13:23 UTC by Callegar
Modified: 2024-03-28 23:46 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document (19.13 KB, application/vnd.oasis.opendocument.presentation)
2019-03-14 13:24 UTC, Callegar
Details
Situation after opening the test document (23.88 KB, image/png)
2019-05-09 10:20 UTC, Callegar
Details
Situation after editing the test document that cannot be preserved in roundtrip (23.53 KB, image/png)
2019-05-09 10:21 UTC, Callegar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2019-03-14 13:23:41 UTC
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
Comment 1 Callegar 2019-03-14 13:24:14 UTC
Created attachment 149967 [details]
Test document
Comment 2 Xisco Faulí 2019-05-09 09:58:42 UTC
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.
Comment 3 Callegar 2019-05-09 10:20:30 UTC
Created attachment 151268 [details]
Situation after opening the test document
Comment 4 Callegar 2019-05-09 10:21:07 UTC
Created attachment 151269 [details]
Situation after editing the test document that cannot be preserved in roundtrip
Comment 5 Callegar 2019-05-09 10:28:50 UTC
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?
Comment 6 QA Administrators 2019-05-14 03:01:52 UTC Comment hidden (obsolete)
Comment 7 raal 2019-05-14 15:24:40 UTC
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)
Comment 8 raal 2019-05-14 16:12:16 UTC
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
Comment 9 Justin L 2022-03-05 13:02:57 UTC
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.
Comment 10 QA Administrators 2024-03-05 03:13:33 UTC Comment hidden (obsolete, spam)
Comment 11 Justin L 2024-03-28 12:42:44 UTC
(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.
Comment 12 Callegar 2024-03-28 23:46:02 UTC
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.