When a drawing has a connector between objects, and the middle line of the connector has been moved significantly, and the whole drawing is selected and copy and pasted into a writer document, the middle line will be offset randomly. See attached image.
Steps to Reproduce:
1. Create a connector between two objects in draw. Make sure you form a connector with an adjustable middle line.
2. Move the middle line by a significant amount. Moving it to imitate a connector with only two lines is generally enough. If the bug isn't reproduced, try moving it farther.
3. Select the whole drawing. Copy and paste it into a writer document
The middle line of the connector in the pasted drawing is offset randomly, neither to where it started originally nor where it was moved to.
The middle line should remain where it was in drawing.
User Profile Reset: Yes
Resizing the pasted drawing at all will reset the middle line to its original position when the connector was created (NOT the position it was adjusted to in step 2.)
The bug happens with and without "Use OpenGL for all rendering" enabled. But regardless of whether I have that enabled there's some text below it that says "GL is currently disabled." Not sure if that refers to OpenGL.
Version: 22.214.171.124 (x64)
Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU thread: 4; OS: Windows 6.1; UI render: default;
Locale: en-US(en_US); Calc: group threaded
Created attachment 145633 [details]
Demonstration of bug
Forgot to mention. I don't believe this is related to https://bugs.documentfoundation.org/show_bug.cgi?id=54355 which is somewhat similar. Zooming has no effect whatsoever on it, and grouping the drawing before copying it doesn't prevent it.
Created attachment 146588 [details]
I can't reproduce it using the attached document
ID de la construcció: 1:6.1.3~rc2-0ubuntu0.16.04.1
Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3;
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Created attachment 147491 [details]
Here's an example which I've just tested with Libreoffice 126.96.36.199
The reason your sample doesn't exhibit the bug is because it doesn't have the middle line (the connector needs to have a total of 3 lines, and the middle line needs to be adjusted from its default position). So the connector needs to be between two points such that the middle line is present. The position of this adjusted middle line is messed up when copying it into a writer document.
Once the update is finished on my other computer, I'll test it on 6.1.3 as you requested.
Tested on 188.8.131.52 and it still occurs.
I see the described problem in Version: 184.108.40.206 (x64)
CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard;
Gebietsschema: de-DE (en_US); Calc: CL
Build ID: 6dc36d343aeacb3d1e14ec0c847937d63f4e68a7
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
but not in
Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Working on debian-buster with bibisect-linux-64-6.1 repository, I find
that that bug entered LibreOffice somewhere in roughly 1200 commits:
commit s-h date
-------- -------- ----------
bfr first crash c5420f11 e1b247a8 2018-04-06
first crash c91d6907 6c14c27c 2018-04-06
last crash 083cb644 bdccb7e9 2018-05-07
aft last crash c28a56d0 91b0d212 2018-05-07
Each crash was a Signal 6. The commits from "first crash" to "last
crash", so far as I probed them, terminated with Signal 6 upon
<Ctrl>+V in Writer. Some later commits, starting with the one
labelled "aft last crash" displayed the expected result after <Ctrl>+V
in Writer and then terminated with Signal 6 upon <Ctrl>+Q. I have not
made any attempt to dig into the crashes.
I am leaving keyword bibisectRequest: perhaps the crash is peculiar to