Created attachment 143462 [details] comparison MSO 2010 and LibreOffice 6.2 Steps to reproduce: 1. Open attachment 121466 [details] from bug 96640 -> The drawing object has an incorrect size. See attached image Reproduced in Version: 6.2.0.0.alpha0+ Build ID: c290f692dd28094d41dff686f3faa1c4e14b556e CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=36bade04d3780bc54c51b46bb0b63e69789658a5 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-06-28 19:48:59 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-07-02 18:03:44 +0200 commit 36bade04d3780bc54c51b46bb0b63e69789658a5 (patch) tree c4465bf33aa2cda65511a2c094688522e9c9b43a parent 942f1056b51e53358d42ff8da8a1bbdce9ba5303 (diff) tdf106792 Get rid of SvxShapePolyPolygonBezier Bisected with: bibisect-linux64-6.2 Adding Cc: to Armin Le Grand
Created attachment 143483 [details] Reduced test document The objects in the drawing do not have a wrong size but a wrong position. Not the entire drawing is affected. The group has a correct position. But some lines outside the group have a wrong position. They are anchored to a paragraph, which has the option "Don't add space between paragraphs of the same style" enabled. In this case LibreOffice calculates a wrong vertical position. The attached file is reduced to test it. Is has two paragraph styles with 20pt margin after. They only differ in the setting "Don't add space between paragraphs of the same style". The lower red line gets the correct position. Here the option is disabled. The upper red line gets a wrong position. There the option is enabled.
Bug 94064 is about attachment 108111 [details], which is now displaying the wrong positioning. I bibisected it to the same commit as blamed in comment 1.
(In reply to Regina Henschel from comment #2) > Created attachment 143483 [details] > Reduced test document > > The objects in the drawing do not have a wrong size but a wrong position. > Not the entire drawing is affected. The group has a correct position. But > some lines outside the group have a wrong position. They are anchored to a > paragraph, which has the option "Don't add space between paragraphs of the > same style" enabled. In this case LibreOffice calculates a wrong vertical > position. > > The attached file is reduced to test it. Is has two paragraph styles with > 20pt margin after. They only differ in the setting "Don't add space between > paragraphs of the same style". The lower red line gets the correct position. > Here the option is disabled. The upper red line gets a wrong position. There > the option is enabled. @Regina, I fixed your issue in https://git.libreoffice.org/core/+/713c6b1880ee06f8ff0aa869906058f247db6e3a%5E%21 commit, but this patch could not fixed the original issue. Probably there is another problem which causes this error.
The source commit from Armin's fix in bug 106792 is mentioned as regression in: bug 118693 bug 96640 bug 127555 bug 122717 bug 127370 and duplicate in bug 127364 No idea what's that about, but in cases like those an explanation would be nice, is the fix worth so many regressions or it needs a solution for all.
*** Bug 127513 has been marked as a duplicate of this bug. ***
*** Bug 139297 has been marked as a duplicate of this bug. ***
I think there's more than one bug going on here; there's certainly an alignment/offset issue that seems to be common to all of them. But there are some others, in my 139297 there's a line that's done a 90deg turn; a bit of debugging gets me to a disagreement with ImpForceLineAngle.
This is indeed one part of a change caused by that commit; it removes the hack from 96674 which forced vertical/horizontal lines to have a 1 pixel offset to fix this problem. However, that commit did keep the original test case and the original test looks fine - so there's something different about my test case and there's. Reverting it and putting the 96674 hack back in does fix it - but unfortunately the commit message on 96674 says nothing about why it's needed.
Created attachment 168647 [details] A docx with a vertical line that ends up horizontal That commit added a hack to NbcResize that caused it to be skipped if the resize was 1.0 x 1.0; in my case it's 1 x 1.00022 so it happens; I don't understand the detail why - possibly it's because in my test case the line originally had arrows on and it's got: <wp:extent cx="635" cy="2937510"/> .. <a:xfrm> <a:off x="0" y="0"/> <a:ext cx="0" cy="2936880"/> </a:xfrm> where as the existing case has wp:extent cx="0"
Hi Xisco. Please see those regression bugs from comment 5 and see if revert is possible.
(In reply to Timur from comment #5) > The source commit from Armin's fix in bug 106792 is mentioned as regression > in: > > bug 118693 bug 96640 bug 127555 bug 122717 bug 127370 > and duplicate in bug 127364 > > No idea what's that about, but in cases like those an explanation would be > nice, is the fix worth so many regressions or it needs a solution for all. And more are in meta bug 138706.
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: d7ed130f537a81b900c55d222004cc9e88c0b355 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Armin, any chance you could take a look at this issue ?
I think I know how to fix this...
*** Bug 131275 has been marked as a duplicate of this bug. ***
*** Bug 139651 has been marked as a duplicate of this bug. ***
*** Bug 127463 has been marked as a duplicate of this bug. ***
*** Bug 127370 has been marked as a duplicate of this bug. ***
*** Bug 96640 has been marked as a duplicate of this bug. ***
*** Bug 127555 has been marked as a duplicate of this bug. ***
Patch in gerrit: https://gerrit.libreoffice.org/c/core/+/112663. I believe there might be other duplicates in Bugzilla...
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c9e5640c8fcad7beb42a66f9bee0252eee9fe323 tdf#118693: no need to use convertMm100ToTwip() for line shapes anymore It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 135135 has been marked as a duplicate of this bug. ***
Thanks for the patch, I'll test it early next week.
@Timur, if you have some time, please look for duplicates...
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/b393336817a64f8703607d3f6de37d0b6498d49c tdf#118693: no need to use convertMm100ToTwip() for line shapes anymore It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/ddf13fc815903238c90aa963af7e0ea96fe7280d tdf#118693: no need to use convertMm100ToTwip() for line shapes anymore It will be available in 7.0.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I split out my rotated line bug from comment 10 into separate bug 141120
I can confirm that fixes my example diagram from 139297 (except for the separate rotated line) The diagram from 93675 still renders very differently when ungrouped and saved to docx and back (some bits worse, some bits better).
I checked the duplicates and set verified. bug 93675 is not related, there are more diagram bugs.
I can confirm the bug is fixed using the reproduction steps from bug 127513.
I confirmed that this resolves https://bugs.documentfoundation.org/show_bug.cgi?id=139651 I am unfamiliar with the release procedures, will this eventually find it's way into collabora online office? If yes, how can I track this?
(In reply to olivier.magloire from comment #32) > I confirmed that this resolves > https://bugs.documentfoundation.org/show_bug.cgi?id=139651 > > I am unfamiliar with the release procedures, will this eventually find it's > way into collabora online office? If yes, how can I track this? I guess Aron or Andras can answer to that question
(In reply to Xisco Faulí from comment #33) > (In reply to olivier.magloire from comment #32) > > I confirmed that this resolves > > https://bugs.documentfoundation.org/show_bug.cgi?id=139651 > > > > I am unfamiliar with the release procedures, will this eventually find it's > > way into collabora online office? If yes, how can I track this? > > I guess Aron or Andras can answer to that question Thanks for the heads-up Xisco! The fix will be in the next Collabora Online release.
Thanks for the quick reply and the efforts fixing this issue!
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-1-2": https://git.libreoffice.org/core/commit/02b039958b02d32b85fc7e2d3b30fd8bf8e2da87 tdf#118693: no need to use convertMm100ToTwip() for line shapes anymore It will be available in 7.1.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 134635 has been marked as a duplicate of this bug. ***