Bug 118693 - FILEOPEN: Drawing has incorrect size
Summary: FILEOPEN: Drawing has incorrect size
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: high major
Assignee: Xisco Faulí
URL:
Whiteboard: target:7.2.0 target:7.1.2 target:7.0.6
Keywords: bibisected, bisected, regression
: 127370 127463 127513 127555 131275 135135 139297 139651 (view as bug list)
Depends on:
Blocks: OOXML-Shapes Regress-elim-SvxShapePolyPolygonBezier
  Show dependency treegraph
 
Reported: 2018-07-11 13:39 UTC by Xisco Faulí
Modified: 2021-03-25 12:00 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
comparison MSO 2010 and LibreOffice 6.2 (226.96 KB, image/png)
2018-07-11 13:39 UTC, Xisco Faulí
Details
Reduced test document (17.88 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-11 17:05 UTC, Regina Henschel
Details
A docx with a vertical line that ends up horizontal (4.82 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-01-03 20:30 UTC, Dave Gilbert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2018-07-11 13:39:31 UTC
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]
Comment 1 Xisco Faulí 2018-07-11 13:42:35 UTC
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
Comment 2 Regina Henschel 2018-07-11 17:05:16 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2018-11-26 14:43:06 UTC
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.
Comment 4 Balázs Regényi 2020-07-21 08:41:04 UTC
(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.
Comment 5 Timur 2020-08-01 20:04:37 UTC Comment hidden (obsolete)
Comment 6 NISZ LibreOffice Team 2020-11-30 15:07:03 UTC
*** Bug 127513 has been marked as a duplicate of this bug. ***
Comment 7 NISZ LibreOffice Team 2020-12-30 09:46:23 UTC
*** Bug 139297 has been marked as a duplicate of this bug. ***
Comment 8 Dave Gilbert 2021-01-02 00:51:01 UTC
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.
Comment 9 Dave Gilbert 2021-01-03 03:26:33 UTC
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.
Comment 10 Dave Gilbert 2021-01-03 20:30:42 UTC
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"
Comment 11 Timur 2021-03-17 08:19:43 UTC Comment hidden (obsolete)
Comment 12 Timur 2021-03-17 08:26:14 UTC
(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.
Comment 13 Xisco Faulí 2021-03-17 17:18:52 UTC
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 ?
Comment 14 Xisco Faulí 2021-03-17 23:06:56 UTC
I think I know how to fix this...
Comment 15 Xisco Faulí 2021-03-17 23:09:17 UTC
*** Bug 131275 has been marked as a duplicate of this bug. ***
Comment 16 Xisco Faulí 2021-03-17 23:10:00 UTC
*** Bug 139651 has been marked as a duplicate of this bug. ***
Comment 17 Xisco Faulí 2021-03-17 23:13:09 UTC
*** Bug 127463 has been marked as a duplicate of this bug. ***
Comment 18 Xisco Faulí 2021-03-17 23:13:28 UTC
*** Bug 127370 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2021-03-17 23:14:54 UTC
*** Bug 96640 has been marked as a duplicate of this bug. ***
Comment 20 Aron Budea 2021-03-17 23:39:15 UTC
*** Bug 127555 has been marked as a duplicate of this bug. ***
Comment 21 Xisco Faulí 2021-03-17 23:56:40 UTC
Patch in gerrit: https://gerrit.libreoffice.org/c/core/+/112663. I believe there might be other duplicates in Bugzilla...
Comment 22 Commit Notification 2021-03-18 08:16:01 UTC
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.
Comment 23 Xisco Faulí 2021-03-18 09:01:19 UTC
*** Bug 135135 has been marked as a duplicate of this bug. ***
Comment 24 olivier.magloire 2021-03-18 09:09:38 UTC
Thanks for the patch, I'll test it early next week.
Comment 25 Xisco Faulí 2021-03-18 09:15:43 UTC
@Timur, if you have some time, please look for duplicates...
Comment 26 Commit Notification 2021-03-18 12:37:11 UTC
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.
Comment 27 Commit Notification 2021-03-18 14:21:27 UTC
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.
Comment 28 Dave Gilbert 2021-03-20 02:25:40 UTC
I split out my rotated line bug from comment 10 into separate bug 141120
Comment 29 Dave Gilbert 2021-03-20 02:42:50 UTC
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).
Comment 30 Timur 2021-03-20 08:19:49 UTC
I checked the duplicates and set verified. 
bug 93675 is not related, there are more diagram bugs.
Comment 31 christoph_egger 2021-03-20 14:37:05 UTC
I can confirm the bug is fixed using the reproduction steps from bug 127513.
Comment 32 olivier.magloire 2021-03-22 13:46:22 UTC Comment hidden (obsolete)
Comment 33 Xisco Faulí 2021-03-22 14:04:58 UTC Comment hidden (obsolete)
Comment 34 Andras Timar 2021-03-22 14:14:53 UTC
(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.
Comment 35 olivier.magloire 2021-03-22 14:50:48 UTC
Thanks for the quick reply and the efforts fixing this issue!
Comment 36 Commit Notification 2021-03-24 13:33:14 UTC
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.