Created attachment 109895 [details] Test file with legend manually placed Description: Legend in chart appears always at top left corner if it has been manually placed Steps to reproduce: 1. Create a chart 2. Click and drop legend to move it inside Chart 3. Save 4. Reload Actual behavior: Legend appears at top left corner Expected behavior: Legend should be at the place it has been placed Reproduced with LibO 4.4.0.0.beta1 Not reproduced with LibO 4.3.4.1
Reproduced with - Version: 4.4.0.0.alpha2+ Build ID: 6143fa5a89d9528fc11fed1e7fe96b9280d411a4 TinderBox: Win-x86@42, Branch:master, Time: 2014-11-10_22:48:21 - Version: 4.4.0.0.alpha1+ Build ID: 9ecac3874d179b1d7aa6b45337001b1def06a9dd TinderBox: Win-x86@42, Branch:master, Time: 2014-10-22_06:31:01 - Version: 4.4.0.0.alpha0+ Build ID: 6a6e8628bdbe60931ce8e7fa9f4bb66170f7737b TinderBox: Win-x86@42, Branch:master, Time: 2014-09-29_23:55:43 NOT reproduced with - Version: 4.4.0.0.alpha0+ Build ID: 37b9ea92ba81d74764a2345a9c75c65bfd272d2b TinderBox: Win-x86@42, Branch:master, Time: 2014-08-26_09:37:01 So regression introduced between 2014-08-26_09:37:01 and 2014-09-29_23:55:43
*** Bug 88957 has been marked as a duplicate of this bug. ***
This sounds like it was the same as bug 88848. If so, which of the two should be marked as a duplicate?
bibisected by Michael Weghorn 2015-01-30 19:48:26 UTC comment 2 from bug 88848 $ git bisect log # bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # good: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect good 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # bad: [a42da134cd542144fca7ba14cce86c2b409fc18a] source-hash-beadebc0f7eb5582fcb8dcb082d19afdf2751876 git bisect bad a42da134cd542144fca7ba14cce86c2b409fc18a # bad: [5f697ca821720f76105e5539f0408e68a0647481] source-hash-f9695150942341a755a43996d4639eb623d7640b git bisect bad 5f697ca821720f76105e5539f0408e68a0647481 # bad: [3b00b662438462a4b73b0531ffa6192fc7e72638] source-hash-0a5cd87e591d7f87bfab92716079af719259f143 git bisect bad 3b00b662438462a4b73b0531ffa6192fc7e72638 # good: [b4320c4383b3d61076ac1794797bd3162612889d] source-hash-da21f7da44dc577a08ea3bc210083dc8decf18bc git bisect good b4320c4383b3d61076ac1794797bd3162612889d # bad: [e1690f3a96306b42e829d63cb23a48e4b90603b5] source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06 git bisect bad e1690f3a96306b42e829d63cb23a48e4b90603b5 # bad: [5de848a6e0a36f6ba90e6c32fd126942fde3293c] source-hash-fd0a49bdd7cf7979d18feff003d1b5fbe53fdc14 git bisect bad 5de848a6e0a36f6ba90e6c32fd126942fde3293c # bad: [153f4f2366399a0459129b5161cda0f3b9c0dfbc] source-hash-647f83afb618acbf75c8c6f0a4531bd1e76d8a7e git bisect bad 153f4f2366399a0459129b5161cda0f3b9c0dfbc # first bad commit: [153f4f2366399a0459129b5161cda0f3b9c0dfbc] source-hash-647f83afb618acbf75c8c6f0a4531bd1e76d8a7e
(In reply to Michael Weghorn from comment #3) > This sounds like it was the same as bug 88848. > > If so, which of the two should be marked as a duplicate? Yes, it is a duplicate. An algorithm of the bug reproduction is the same. But I am interested in another thing. Why did not we set "bloked"? Our rules of the version release suggest that a regression compared with the previous version is a reason to block the release. https://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Definition However, we stated that everything was normal, it was just a working situation. Why do we produce the program with unusable functionality?
I've got the same problem in 4.4.0.3 (40m0(Build:3) ) after upgrade.
I confirm this bug. The bug first occured after upgrading from Version 4.3.5~rc2-0ubuntu1~precise1 to 4.4.0-rc3-0ubuntu1-precise1. I am using Ubuntu 12.04
*** Bug 89081 has been marked as a duplicate of this bug. ***
*** Bug 89148 has been marked as a duplicate of this bug. ***
*** Bug 89163 has been marked as a duplicate of this bug. ***
*** Bug 89200 has been marked as a duplicate of this bug. ***
*** Bug 89371 has been marked as a duplicate of this bug. ***
Hello, As i told in Bug 89371, tried to get out of the stable branch by testing the 4.4.0.3., where i discovered this bug, that forbids me to use libreoffice : what is more important in profesional use than diagrams ? So i came back to stable branch. Please note also that the legend moves also when i generate pdf, so i cannot even place all legends then makes pdf to keep the rigth view.
Hello, The bug is still there on version 4.4.1.1 I'm using Windows XP
Still a problem in Version: 4.4.1.2 Build ID: 40m0(Build:2) (ubuntu 14.04).
I can confirm the problem remains with the windows 4.4.1.2 version as well. Build ID: 45e2de17......
Setting priority to highest as this is a 4.4 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
The same problem with 4.4.2.1 Linux 32bit (mageia4)
Really annoying. This also happens for charts in writer.
This seems to have been introduced by the below commit commit b067ead2ee8f162374c81b35190b0201a306ae04 Author: Kohei Yoshida <kohei.yoshida@collabora.com> AuthorDate: Wed Sep 24 16:16:54 2014 -0400 Commit: Kohei Yoshida <kohei.yoshida@collabora.com> CommitDate: Wed Sep 24 16:19:27 2014 -0400 Don't update chart view when the controllers are locked. Change-Id: I8468925e63db3a5cc5ef3e0f942d22478fd0863e
*** Bug 90109 has been marked as a duplicate of this bug. ***
For such a high priority issue things seems strangely quiet here. It's not even assigned yet. With no projected fix in sight I am having to considering downgrading my version, which will be somewhat painful since other previously resolved problems will come back and bite me in thecposterior. Is there any likelihood of getting some information about when or if this problem will be looked at?
Still present in Version: 4.4.2.2, Build ID: 40m0(Build:2), Locale: en_GB
Legend is moved if you copy the chart. It means that you cannot even copy-and-paste a chart correctly. However, the legend is not moved if you export the chart. My version: 4.4.2.2 This makes the involved LO versions useless if legend should be moved.
The file modified with 4.4 opened with Version: 4.3.6.2 looks good: the legend is in the position where it was moved to in 4.4, although 4.4 does not display it correctly.
(In reply to Matthew Francis from comment #20) > This seems to have been introduced by the below commit > > commit b067ead2ee8f162374c81b35190b0201a306ae04 > Author: Kohei Yoshida <kohei.yoshida@collabora.com> > AuthorDate: Wed Sep 24 16:16:54 2014 -0400 > Commit: Kohei Yoshida <kohei.yoshida@collabora.com> > CommitDate: Wed Sep 24 16:19:27 2014 -0400 > > Don't update chart view when the controllers are locked. I can confirm that this commit introduced the bug, with the ability to skip update if controllers are locked. However in SchXMLLegendContext::StartElement opengrok.libreoffice.org/xref/core/xmloff/source/chart/SchXMLLegendContext.cxx#197 xLegendShape->setSize( aLegendSize ); there is a call to impl_updateView() (through ChartView::getRectangleOfObject) http://opengrok.libreoffice.org/xref/core/chart2/source/view/main/ChartView.cxx#1943 and there it needs an update. I proposed a dirty fix in ChartView::getRectangleOfObject if it is called for a legend: https://gerrit.libreoffice.org/15268/ may be not so nice, but it fixes the bug on my master. May be Kohei would have a better way to fix it.
*** Bug 90581 has been marked as a duplicate of this bug. ***
Should be noted that the start center thumbnail shows the legend in the correct location. attachment 114755 [details]
(In reply to Jay Philips from comment #28) > Should be noted that the start center thumbnail shows the legend in the > correct location. attachment 114755 [details] What you see in start center, is just a preview image stored when the file was saved. It is not calculated by LibO. So, in this case, image just says that when the file was saved, legend was at the right place.
The solution I proposed is not acceptable.
(In reply to Laurent BP from comment #29) > What you see in start center, is just a preview image stored when the file > was saved. It is not calculated by LibO. So, in this case, image just says > that when the file was saved, legend was at the right place. No this is incorrect. <kendy> jphilipz: ... there are 2 thumbnails: one in ODF, one for the startcenter. <kendy> jphilipz: In the older LibreOffice versions, the one from the file were shown, now we use the one in the profile.
Still present in 4.4.3.1 Linux 32 bit
Returning it back to 4.4 master.
*** Bug 90743 has been marked as a duplicate of this bug. ***
I've done some debugging and found the following results: 1) creating a chart with arbitrary location of the legend; and saved it to .ods. 2) I've unzipped the .ods file 3) I've examined ~/Object 1/content.xml there's a tag <chart: legend svg:x="XVALUE" svg:y="YVALUE" ... it seems that XVALUE and YVALUE contain the correct legend's location, in cm. Then I've reopened the .ods file and the legend moved to top-left corner of the chart. 4) I've resaved the incorrect location of the legend into a new .ods file 5) I've unzipped the new .ods file 6) examining ~/Object 1/content.xml The XVALUE and YVALUE are not both set to zero (since the legend was in the top-left corner). My conclusion is that since the XVALUE and YVALUE were properly saved, the problem is during opening of the .ods file. Also. If I use one of the presents (top, bottom, left, right) for the legend position the content.xml file has chart:legend-position="MYPOSITION". 8) Then if I manually edit content.xml to change "MYPOSITION" to "MYPOSITION2" 9) rezip the files back to .ods file 10) opening the newely zipped .ods file in Calc properly reflects MYPOSITION2 for the legend. This further concludes that during the opening Calc has trouble parsing the svg:x="XVALUE" and svg:y="YVALUE" values. But it has no trouble parsing chart:legend-position="POSITION" when top/bottom/left/right is used.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=774257d6708ea059c108ac2831a583dafc385370 it works if we first set the size and then the position, tdf#86624 It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf52d1951587bea895902c8b030a19942dd0ba69 add test for tdf#86624 It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks moggi :) I'll test it as soon as possible.
I can confirm that bug is fixed on master. It now needs to be backported on 4.4. Surely too late for 4.4.3, but would be great for 4.4.4 ;)
Backport to 4.4 is on the way :) https://gerrit.libreoffice.org/15600/
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a01d54ba65d3ef20eebb5f943cfe8a18daad22a8&h=libreoffice-4-4 it works if we first set the size and then the position, tdf#86624 It will be available in 4.4.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It works for me on win XP. LO 4.4.4 daily of 2015-05-11 Thanks.
Works for me - ubuntu Version: 4.4.4.2 Build ID: 40m0(Build:2) Locale: en_GB.UTF-8
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]