Bug 70210 - FILEOPEN, REGRESSION: draw and impress do not load connector skew properly and consequently break documents on saving again
Summary: FILEOPEN, REGRESSION: draw and impress do not load connector skew properly an...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: highest blocker
Assignee: Andras Timar
Whiteboard: BSA target:4.2.0 target:4.1.4
Keywords: regression
: 52245 68104 69415 70628 70954 70974 71126 71143 71220 72067 72227 72815 (view as bug list)
Depends on:
Reported: 2013-10-06 19:54 UTC by Callegar
Modified: 2013-12-28 18:13 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:

Sample document to demonstrate the issue (11.80 KB, application/vnd.oasis.opendocument.presentation)
2013-10-06 19:54 UTC, Callegar

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2013-10-06 19:54:31 UTC
Created attachment 87208 [details]
Sample document to demonstrate the issue

When saving/loadinig a presentation/drawing with connectors, all the connectors skews are lost. Older documents with connectors formatted with line skew are corrupted by losing the connector formatting in load/save/load cycle.

To demo the issue:

1) Load the attached document test.odp
2) Right click on the lower connector and open the connector properties. See that all the line skews are at 0.
3) Change the line skews, so that for line 1 it is 1cm and for line 3 it is -0.60 cm
4) Save the document
5) Reload the document and visually see that the connector line skews have changed
6) Right click on the lower connector and open the connector properties. See that all the line skews have been reset at 0.

To me, this is a major issue:

1) Means that draw/impress cannot be used anymore to draw block diagrams and flow charts properly
2) Means that libreoffice now corrupts drawings/presentations in load/save/load cycle
3) Means that all older docs when opened with newer libreoffice and resaved get corrupted and lose connector formatting

I'm rather sure that openoffice in the past used to manage connector skews properly. Probably also past versions of libreoffice did it right, so this is definitely a regression. However I would not be able to say which versions of openoffice/libreoffice were correct.

In any case, this is a regression shared also by openoffice 4.0.  Maybe it was 'imported' together with changes introduced with openoffice 4.

The bug is seen in Linux on an X86-64 Kubuntu raring machine, with libreoffice packages downloaded from the libreoffice site. But probably the bug applies to all hardware platforms and OSs.
Comment 1 Callegar 2013-10-06 20:18:56 UTC

Bug is confirmed and actually fixed for Openoffice. Fix is in Openoffice 4.0.1.

By simultaneously using libreoffice and openoffice 4.0.1, one can conclude that libreoffice /saves/ the skews correctly, but ignores them (or resets them) on loading the files.

Please, port the Openoffice fix asap! I realized about this issue late and already I have many many presentations to check for corruption.
Comment 2 Callegar 2013-10-09 10:18:47 UTC
One more note about why this bug is quite serious.

Say that you have >100 presentations and that you have drawings in them where you use connectors (e.g. electronic schematics, where connectors are a handy way to do wires since they let things stay connected when positions of component are slightly rearranged, or diagrams or flowcharts).

Say that for some reason you need to change an affiliation in the first slide.

So, you open the documents one by one, you go to the first slide, you fix the affiliation, you save. Since you are just fixing something in the first slide, you do not even look at the other ones.

One month later you realize that many of your diagrams in all your >100 presentations are now broken.

A side note.  LibO should probably have automatic testing in place for this kind of LOAD/SAVE consistency issues.  It can probably suffice to have some test docs for which doc is just opened and re-saved without any editing and then the saved doc is compared to the original test document for differences.
Comment 3 post+libreoffice 2013-10-10 13:50:10 UTC
The same bug is tracked in OpenOffice (and has been fixed there) at https://issues.apache.org/ooo/show_bug.cgi?id=123048
Comment 4 ign_christian 2013-10-10 14:32:34 UTC
Hi.. It's possibly duplicate to one of these bugs:
Bug 69415
Bug 68104
Bug 52245
Bug 43533
Comment 5 Callegar 2013-10-21 15:56:06 UTC
Fixed bug title.

One can easily verify, by comparing with Apache Openoffice, that the bug is just in the file open path.

From the number of duplicates it seems like this is a problematic issue to many.
Note that in Apache this was considered a release blocker.

Fix in 

please port for 4.1.3.

See also
Comment 6 Callegar 2013-10-24 08:38:47 UTC
*** Bug 69415 has been marked as a duplicate of this bug. ***
Comment 7 Callegar 2013-10-24 08:39:46 UTC
*** Bug 68104 has been marked as a duplicate of this bug. ***
Comment 8 David Clayton 2013-10-24 15:15:24 UTC
I have changed the platform to all as this affects both Linux and Windows, updated the importance to high as this 'damages' existing documents for other users.
Comment 9 David Clayton 2013-10-24 15:17:00 UTC
*** Bug 52245 has been marked as a duplicate of this bug. ***
Comment 10 Callegar 2013-10-24 15:17:39 UTC
Apparently 4.1.3 RC2 is out with no fix for this issue.

Is a 4.1.3 RC3 being considered?

I wish that LO QA could consider this bug a release blocker as Apache Openoffice QA did.

Please, consider once more that the current behavior means that you open a document and when you save it again (regardless whether it was modified or not), the document gets corrupted.

With this issue, Libreoffice is not just misrendering draw/impress documents, it is actively destroying people's work and in a very subtle way (user changes title in first slide and the 100 following slides have their diagrams made useless when he saves). User may realize at the very important presentation of his life. 

This may mean throwing away users' manmonths work.  I spent the last day fixing back some slides of mine using AOO.
Comment 11 Andy 2013-10-26 06:49:09 UTC
This bug is also a major problem for me as it has corrupted a number of business documents I have. I would urge someone to pick it up as soon as possible.
Comment 12 Regina Henschel 2013-11-02 00:24:08 UTC
*** Bug 71143 has been marked as a duplicate of this bug. ***
Comment 13 Regina Henschel 2013-11-02 00:24:58 UTC
*** Bug 70974 has been marked as a duplicate of this bug. ***
Comment 14 Regina Henschel 2013-11-02 00:26:23 UTC
*** Bug 70954 has been marked as a duplicate of this bug. ***
Comment 15 ign_christian 2013-11-02 00:30:59 UTC
*** Bug 71126 has been marked as a duplicate of this bug. ***
Comment 16 ign_christian 2013-11-02 00:35:04 UTC
If I didn't make mistake reproducing, it's not reproducible on LO (Win7 32bit). Maybe regression occur in 4.1.x
Comment 17 Tim 2013-11-02 08:56:41 UTC
I can confirm, this does not seem to be an issue on 4.0.6.

However, on that version there seems to be a bug where a connector with 2 skew lines initially doesn't show all handles after loading (and the one handle it does show is moving in the wrong direction). When I try to make a change to such a connector, the routing is reset and then works as expected after that. I also noticed that the connector dialog for such a connector has the line skew settings disabled.

A connector with 1 skew line seems to have no problems at all on 4.0.6. I have not tested connectors with 3 skew lines.

So it's not perfect on 4.0.6, but I would call it an annoyance.
Comment 18 Callegar 2013-11-03 22:31:21 UTC
The fact that the release notes of 4.1.3 do not even mention the possibility of ruining existing documents may get judged as unfortunate by some users.  Particularly, because 4.1 is now indicated as 'recommended'.

Please, at least update the release notes.
Comment 19 Sean 2013-11-04 13:23:42 UTC
This is, arguably, one of the most pressing bugs in Draw (perhaps all of LibreOffice) as it, effectivly, shuts down Draw's ability to be used for anything but the most basic diagrams.  This has been around for months (at least) and needs to be fixed.

Comment 20 Callegar 2013-11-04 13:44:22 UTC
I would like to underline again that it is even worse than that.

I would not complain this loudly if for some versions of LibO there was no draw and impress at all or if it was simply unusable.

The problem is that this defect makes LibO /appear/ useful, while it is in fact actively destroying a potentially large amount of previous document preparation work from the users.  I am still through reconstructing my slides with LibO 4.0 and AOO 4.0.1. This is a huge issue, and the most damaging thing that could be done to the perception of LibO and free software. People biten by this issue may make the association 'It's free so it is risky. I must expect that it can deteriorate my data in unpredictable ways.'.

Hence, again. Please, put a warning in the release notes for the 4.1 series until this is fixed.
Comment 21 ign_christian 2013-11-05 01:13:15 UTC
*** Bug 71220 has been marked as a duplicate of this bug. ***
Comment 22 Jorendc 2013-11-05 19:19:52 UTC
Looks like it is fixed (backported from AOO) http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c03fc2fe77f9b1f910f4ab395923e52648c32b5

Can someone verify this, tested using a master-build http://dev-builds.libreoffice.org/daily/master/ ?

This fix is _NOT_ backported (yet) to 4.1 branch. I'm not sure it's possible to do. But please test first on master branch :).

Kind regards,
Comment 23 David Clayton 2013-11-15 14:58:27 UTC
I have changed the status to blocker as I feel that 4.1.4 should not be released without addressing this issue, owing to the fact it 'damages' existing documents for other users. I am slightly disappointed that this bug has not received an official LO developer  reply, to say it was posted in October and has such an impact.
Comment 24 Kristaps Enkuzens 2013-11-16 08:56:32 UTC
I can verify that the bug is fixed in master build. Tested on, MacOSX. Tested with the bug attachment document and some other documents.
Comment 25 Andras Timar 2013-11-19 13:23:00 UTC
I cherry-picked the fix to libreoffice-4-1 branch.
Comment 26 Callegar 2013-11-30 10:08:55 UTC
Seems unmentioned in https://wiki.documentfoundation.org/Releases/4.1.4/RC1

Is the fix actually getting in 4.1.4?
Comment 27 Andras Timar 2013-11-30 10:34:09 UTC
(In reply to comment #26)
> Seems unmentioned in https://wiki.documentfoundation.org/Releases/4.1.4/RC1
> Is the fix actually getting in 4.1.4?

It must be my mistake, I did not push it, or something like this. Now it requires more reviews on gerrit, for 4.1.4 rc2.
Comment 28 Callegar 2013-11-30 10:42:02 UTC
Thanks for the clarification.

Please, do all that is possible so that it actually gets in 4.1.4 RC2 since having LO silently ruin documents even in 4.1.4 would be really bad.

Also, please try to assure that it gets some visibility in the release notes, since this time I really think that people who are on 4.1 *must* upgrade.
Comment 29 Regina Henschel 2013-11-30 23:39:21 UTC
*** Bug 72067 has been marked as a duplicate of this bug. ***
Comment 31 Regina Henschel 2013-12-02 18:01:01 UTC
*** Bug 72227 has been marked as a duplicate of this bug. ***
Comment 32 Callegar 2013-12-03 06:32:48 UTC
Excellent news that the fix is in!  Thanks.
Comment 33 Sean 2013-12-15 18:32:22 UTC
Just updated to on Fedora 19 x64 and the bug appears to be fixed!
Comment 34 David Clayton 2013-12-16 07:54:37 UTC
Hi, I have on Windows 7 and this has the issue. Did (Sean) mean to say he tried 4.1.4 RC2 and it was fixed?
Comment 35 Callegar 2013-12-16 07:59:50 UTC
It is fixed in 4.1.4 RC2. See also https://wiki.documentfoundation.org/Releases/4.1.4/RC2 and particularly note i#123048 line skew parameter is not read from file for connectors in OO draw [Armin Le Grand].

Thanks Andras for taking care of this!
Comment 36 Regina Henschel 2013-12-19 16:32:42 UTC
*** Bug 72815 has been marked as a duplicate of this bug. ***
Comment 37 Sean 2013-12-19 16:43:12 UTC
David Clayton:  I just double checked and I am running on an x64 machine and it is fixed.
Comment 38 Jorendc 2013-12-28 18:13:48 UTC
*** Bug 70628 has been marked as a duplicate of this bug. ***