Bug 126896 - FILESAVE: On roundtrip the information line joint is lost
Summary: FILESAVE: On roundtrip the information line joint is lost
Status: RESOLVED DUPLICATE of bug 126746
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pptx
Depends on:
Blocks:
 
Reported: 2019-08-13 21:20 UTC by Regina Henschel
Modified: 2019-09-03 16:14 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Shape with zigzag line as custGeom with LineJoint = "Miter" (16.27 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2019-08-13 21:20 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2019-08-13 21:20:11 UTC
Created attachment 153360 [details]
Shape with zigzag line as custGeom with LineJoint = "Miter"

The attached file contains a zigzag line as custGeom shape with lnTo commands. The problem can be seen too if you use the shape "Callout Bent Line" in PowerPoint. In that case drag the handles, so that you get a sharp corner. Test it with a large line width to make the joint types better visible.

If you open the file and re-save it to pptx in LibreOffice and then open the re-saved file, the line joint "Miter" is gone and line joint "Round" is used.

The information is correctly read and I see the correct values in in the shape in the Basic IDE. The method DrawingML::WriteOutline() gets the case aStyleLineJoint == eLineJoint when treating the property LineJoint and thus does not write the a:miter element at the shape. But if you examine the re-saved file, you will notice, that the element <a:miter> is missing in all childs of the <a:lnStyleLst>.

In case of export from our own format there exists no scheme and the <a:miter> element is written at the shape. Therefore there the error does not happen.
Comment 1 Xisco Faulí 2019-09-03 06:51:17 UTC
Hi Regina,
Visually they look the same before and after saving the document.
Where can I check the value changed ?
Comment 2 Regina Henschel 2019-09-03 10:50:57 UTC
Indeed, seems to fixed in the meantime. It is OK now in Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

(The different miter limit is a different problem. The different miter limit is the reason, that the bottom peak is cut in LibreOffic but not in PowerPoint.)
Comment 3 Xisco Faulí 2019-09-03 11:12:59 UTC
Fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=606a88d2abf85aa6edcc1fa26dc50cab6de3241f

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