Bug 127366 - Line not fully drawn for shape "line callout" spanning a A2 presentation
Summary: Line not fully drawn for shape "line callout" spanning a A2 presentation
Status: RESOLVED DUPLICATE of bug 126184
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks:
 
Reported: 2019-09-05 10:51 UTC by Michael Weghorn
Modified: 2019-09-05 15:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document with "line callout 3" shape (10.32 KB, application/vnd.oasis.opendocument.presentation)
2019-09-05 10:51 UTC, Michael Weghorn
Details
PDF export with current master (broken) (6.15 KB, application/pdf)
2019-09-05 10:52 UTC, Michael Weghorn
Details
PDF export with older version (OK) (6.18 KB, application/pdf)
2019-09-05 10:52 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2019-09-05 10:51:31 UTC
Created attachment 153906 [details]
Sample document with "line callout 3" shape

The line of a "line callout 3" shape that spans an A2 presentation is not correctly shown and printed (any more).

# Steps to reproduce:

1) start Impress
2) set slide format to A2 (not reproducible e.g. with A4)
3) select to insert "Line Callout 3" (menu: "Insert" -> "Shape" -> "Callouts" -> "Line Callout 3")
4) make the callout go from top left to bottom right of the slide (i.e. click in top-left corner, drag to bottom right)

or easier:

open attached document "callout.odp"

# Result:

The blue line starts at the top-left, but ends quite distance away from the blue "box" in the bottom right corner, i.e. it is too short.

# Expected result:

The blue line should end very close to the "blue box" in the bottom right corner.


Version: 6.4.0.0.alpha0+
Build ID: 0f3fb26e7622f99560c6514f4b3ae663636025c9
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

Also reproducible on Windows.
Comment 1 Michael Weghorn 2019-09-05 10:52:02 UTC
Created attachment 153907 [details]
PDF export with current master (broken)
Comment 2 Michael Weghorn 2019-09-05 10:52:21 UTC
Created attachment 153908 [details]
PDF export with older version (OK)
Comment 3 Michael Weghorn 2019-09-05 10:56:39 UTC
The same issue is visible after doing a PDF export of the slide (s. attachments)

Bibisect result using "bibisect-linux-64-6.1" repo shows it regresses here:

    commit e67255c720d5acfe720dc85eec1aa93d6875a6a0
    Author: Jenkins Build User <tdf@pollux.tdf>
    Date:   Sat Mar 17 23:29:14 2018 +0100

        source 735d9e5828157a09e0b04b2dc5797a78208b57a2
        
        source 735d9e5828157a09e0b04b2dc5797a78208b57a2
        source 86c4672f4600daf19238ef25377406f445d9453a
        source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba


i.e. at one of the following 3 commits:

    commit 735d9e5828157a09e0b04b2dc5797a78208b57a2
    Author: Armin Le Grand <Armin.Le.Grand@cib.de (CIB)>
    Date:   Thu Mar 15 11:32:00 2018 +0100

        OperationSmiley: Secured quite some places using CustomShape
        
        Changed quite some places of SdrObjCustomShape usage to use
        references instead of pointers, thus forcing to more secure
        handling. Changed some test and change methods, even found a
        memory leak by doing so.
        Added some incudes/predefines for linux builds.
        
        Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7

    commit 86c4672f4600daf19238ef25377406f445d9453a
    Author: Armin Le Grand <Armin.Le.Grand@cib.de (CIB)>
    Date:   Thu Mar 15 11:32:00 2018 +0100

        OperationSmiley: Secured quite some places using CustomShape
        
        Changed quite some places of SdrObjCustomShape usage to use
        references instead of pointers, thus forcing to more secure
        handling. Changed some test and change methods, even found a
        memory leak by doing so.
        
        Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7

    commit d1027af3c74529827d53e8cf7b0d42a0ee47d1ba
    Author: Armin Le Grand <Armin.Le.Grand@cib.de (CIB)>
    Date:   Fri Feb 23 16:57:41 2018 +0100

        OperationSmiley: Added support for using same FillGeometry
        
        It is now possible to use a single FillGeometry to fill objects that
        are made of multiple filled objects (e.g. CustomShapes) so that
        they look as using a single fill. This is used for CustomShapes,
        but may later be 'extended' to be used for more cases. The basic
        functionality was already in the primitives, but had to be added
        to SDrObject due to these being used for CustomShapeVisualization
        (currently - would be better to change this to primitives, too).
        
        Change-Id: I1d9fb158191a9ec663e46f3911213be2f3d88986

Adding Cc: to Armin Le Grand

(I'm self-confirming according to [1] since the issue has initially been reported by someone else in our internal issue tracker.)

[1] https://wiki.documentfoundation.org/QA/Guidelines_for_public_and_private_sector_deployments
Comment 4 Regina Henschel 2019-09-05 13:25:28 UTC
I would say, it is duplicate to bug 126184. It is the same "42cm" problem, see my analysis there.

I have written a mail to Armin, but besides a note, that he had got my mail, I have not got any information from him in regard of a better fix for bug 63955.
Comment 5 Michael Weghorn 2019-09-05 15:16:21 UTC
(In reply to Regina Henschel from comment #4)
> I would say, it is duplicate to bug 126184. It is the same "42cm" problem,
> see my analysis there.
> 
> I have written a mail to Armin, but besides a note, that he had got my mail,
> I have not got any information from him in regard of a better fix for bug
> 63955.

Thanks a lot for that information and the analysis. Looking at your analysis in bug 126184 and at the other bugs referenced from there, this really looks like the same issue.

*** This bug has been marked as a duplicate of bug 126184 ***