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.
Update. 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.
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.
The same bug is tracked in OpenOffice (and has been fixed there) at https://issues.apache.org/ooo/show_bug.cgi?id=123048
Hi.. It's possibly duplicate to one of these bugs: Bug 69415 Bug 68104 Bug 52245 Bug 43533
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 http://svn.apache.org/viewvc?view=revision&revision=1519451 please port for 4.1.3. See also https://issues.apache.org/ooo/show_bug.cgi?id=123048
*** Bug 69415 has been marked as a duplicate of this bug. ***
*** Bug 68104 has been marked as a duplicate of this bug. ***
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.
*** Bug 52245 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 71143 has been marked as a duplicate of this bug. ***
*** Bug 70974 has been marked as a duplicate of this bug. ***
*** Bug 70954 has been marked as a duplicate of this bug. ***
*** Bug 71126 has been marked as a duplicate of this bug. ***
If I didn't make mistake reproducing, it's not reproducible on LO 4.0.6.2 (Win7 32bit). Maybe regression occur in 4.1.x
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.
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.
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. Sean
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.
*** Bug 71220 has been marked as a duplicate of this bug. ***
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, Joren
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.
I can verify that the bug is fixed in master build. Tested on 4.2.0.0.alpha1+, MacOSX. Tested with the bug attachment document and some other documents.
I cherry-picked the fix to libreoffice-4-1 branch.
Seems unmentioned in https://wiki.documentfoundation.org/Releases/4.1.4/RC1 Is the fix actually getting in 4.1.4?
(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. https://gerrit.libreoffice.org/#/c/6862/
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.
*** Bug 72067 has been marked as a duplicate of this bug. ***
The fix will be in LibreOffice 4.1.4. http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1-4&id=c2afbdb2f3c575fb29f9d8ceaad94d37ee6a05ac
*** Bug 72227 has been marked as a duplicate of this bug. ***
Excellent news that the fix is in! Thanks.
Just updated to 4.1.3.2 on Fedora 19 x64 and the bug appears to be fixed!
Hi, I have 4.1.3.2 on Windows 7 and this has the issue. Did (Sean) mean to say he tried 4.1.4 RC2 and it was fixed?
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!
*** Bug 72815 has been marked as a duplicate of this bug. ***
David Clayton: I just double checked and I am running 4.1.3.2-11.fc19 on an x64 machine and it is fixed.
*** Bug 70628 has been marked as a duplicate of this bug. ***