Bug Hunting Session
Bug 124077 - Broken roundtrip (save/load) for impress/draw document including tables
Summary: Broken roundtrip (save/load) for impress/draw document including tables
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2019-03-14 13:23 UTC by sergio.callegari
Modified: 2019-05-15 12:07 UTC (History)
3 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, sergio.callegari
Details
Situation after opening the test document (23.88 KB, image/png)
2019-05-09 10:20 UTC, sergio.callegari
Details
Situation after editing the test document that cannot be preserved in roundtrip (23.53 KB, image/png)
2019-05-09 10:21 UTC, sergio.callegari
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 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 sergio.callegari 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 sergio.callegari 2019-05-09 10:20:30 UTC
Created attachment 151268 [details]
Situation after opening the test document
Comment 4 sergio.callegari 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 sergio.callegari 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