if you draw something in draw/impress and define the cap style rounded, this parameter was losed when export to powerpoint. reproduce - draw polygon in draw with line width 0,1 cm - export to powerpoint - open in powerpoint 2010/2016
Created attachment 153199 [details] cup style rounded not used in powerpoint in draw I define cup style rounded but after the powerpoint export in impress, the information get lost.
component "libvisio", Product "Document Liberation Project"? For LibreOffice I can confirm it. Export of linecap is not yet implemented.
Created attachment 153210 [details] Example of LO Impress file
Created attachment 153211 [details] Example of wrongly exported pptx file
Created attachment 153212 [details] Example of wrongly exported pptx file after manual fix by MS Excel To fix the issue the cap="rnd"> property need to be exported in "ppt/slides/slide1.xml". As a result instead of: <a:ln w="182880"> <a:solidFill> <a:srgbClr val="00B0F0"/> </a:solidFill> <a:round/> </a:ln> it should be: <a:ln w="182880" cap="rnd"> <a:solidFill> <a:srgbClr val="00B0F0"/> </a:solidFill> <a:round/> </a:ln>
I was wrong with my previous assumption. The root cause of issue is missing "<a:close/>" for closed shapes. After changing "ppt/slides/slide1.xml" file, from: <a:pathLst> <a:path w="10415" h="6605"> <a:moveTo> <a:pt x="762" y="508"/> </a:moveTo> <a:lnTo> <a:pt x="8890" y="0"/> </a:lnTo> <a:lnTo> <a:pt x="10414" y="4572"/> </a:lnTo> <a:lnTo> <a:pt x="5080" y="6604"/> </a:lnTo> <a:lnTo> <a:pt x="0" y="5588"/> </a:lnTo> <a:lnTo> <a:pt x="762" y="508"/> </a:lnTo> </a:path> </a:pathLst> to: <a:pathLst> <a:path w="10415" h="6605"> <a:moveTo> <a:pt x="762" y="508"/> </a:moveTo> <a:lnTo> <a:pt x="8890" y="0"/> </a:lnTo> <a:lnTo> <a:pt x="10414" y="4572"/> </a:lnTo> <a:lnTo> <a:pt x="5080" y="6604"/> </a:lnTo> <a:lnTo> <a:pt x="0" y="5588"/> </a:lnTo> <a:lnTo> <a:pt x="762" y="508"/> </a:lnTo> <a:close/> </a:path> </a:pathLst>
(In reply to Bartosz from comment #6) > I was wrong with my previous assumption. The root cause of issue is missing > "<a:close/>" for closed shapes. Of cause the export of cap="rnd" is missing. But if you have a solid line style and a closed shape, you will not see a "cap" at all, but only line join. A "cap" is used at the open ends of a line. The problem is likely (I have not tested it!) in https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx. There the element <a:ln> is written in #827. So the "cap" has to be determined before. But the property "LineCap" from the input parameter rXPropSet is not evaluated.
Review: https://gerrit.libreoffice.org/#/c/77179/
The patch is good, but it has nothing to do with line caps. Do you want to treat line caps too? And in this bug report? If not, you should consider to make a new bugreport, this one for closed shapes (change title) and the other for line caps, or the other way round (change reference in patch in that case).
Thanks for support. Currently I am working on line Caps support. I would like to do in this bug report. Is it ok for you?
(In reply to Bartosz from comment #10) > Thanks for support. Currently I am working on line Caps support. I would > like to do in this bug report. Is it ok for you? Yes, no problem.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3feaff84fafc23c26ff9c6a716709f17a6c8330b%5E%21 tdf#126746 Fix exporting closed Polylines to PPTX It will be available in 6.4.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.
@Bartost; "nd101" is working in the same area. You should watch his work, to be aware of merging conflicts. I have attached a zip-container to bug 126741 with remarks on line styles and test documents. That is likely interesting for you too.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/f4a660c38471daa35db2dcfa69fb3ebe56d599b9%5E%21 tdf#126746 Fix exporting closed Polylines to PPTX It will be available in 6.3.1. 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.
Created attachment 153354 [details] ZigZag line with joint and cap made by PowerPoint 365 The caps look correct now in https://gerrit.libreoffice.org/#/c/77233/3 at true line ends. Import of dashed lines gives not the same result as in PowerPoint. But because PowerPoint treats dots really weird, I suggest not to try an improvement in your current patch. But there is an old problem with joint. Joint "Miter" in pptx by PowerPoint is not correctly treated on round-trip. If you open the file and re-save it to pptx in LibreOffice and then open the re-saved file, "Miter" is gone and "Round" is used. The attached file contains a custGeom shape with lnTo commands. The problem can be seen too if you use the shape "Callout Bent Line" in PowerPoint. Drag the handles, so that you get a sharp corner. Test it with a large line width to make the joint types better visible. Perhaps the error is somewhere in the area you are current working and you can fix it too?
(In reply to Regina Henschel from comment #15) > Perhaps the error is somewhere in the area you are current working and you > can fix it too? I have looked a little but around and it seems to be unrelated with your area of work. The shape gets the wrong line joint because the lnStyleLst in fmtScheme is missing the a:miter element, but WriteOutline() assumes that the line joint information is in the schema and therefore does not output it at the shape. I will write a new bug report for that.
(In reply to Regina Henschel from comment #16) > (In reply to Regina Henschel from comment #15) > > Perhaps the error is somewhere in the area you are current working and you > > can fix it too? > > I have looked a little but around and it seems to be unrelated with your > area of work. The shape gets the wrong line joint because the lnStyleLst in > fmtScheme is missing the a:miter element, but WriteOutline() assumes that > the line joint information is in the schema and therefore does not output it > at the shape. I will write a new bug report for that. I'm sorry. Too late. I have already fixed it with latest commit update: https://gerrit.libreoffice.org/#/c/77233/4/sd/source/filter/eppt/pptx-epptooxml.cxx Thanks for your detail testing. It's awesome how well you are testing these changes.
Would it be useful to make a call, where we can talk about related stuff?
Created attachment 153380 [details] File for roundtrip test in xlsx-format Excel file with Callout Bent Line. open and resave in xslx-format. The joint type Miter turns into Round. I have tested Word too. Word does not have this problem.
(In reply to Regina Henschel from comment #19) > Created attachment 153380 [details] > File for roundtrip test in xlsx-format > > Excel file with Callout Bent Line. open and resave in xslx-format. The joint > type Miter turns into Round. > I have tested Word too. Word does not have this problem. The root cause of problem for .xlsx files, is lack of "xl/theme/theme1.xml" file after saving by LibreOffice Calc. This file contain style list. I think it is too much for this bug report, and we should handle this lack of theme for .xlsx in separate bug report. What do you think?
(In reply to Bartosz from comment #20) > (In reply to Regina Henschel from comment #19) > > Created attachment 153380 [details] > > File for roundtrip test in xlsx-format > > > > Excel file with Callout Bent Line. open and resave in xslx-format. The joint > > type Miter turns into Round. > > I have tested Word too. Word does not have this problem. > > The root cause of problem for .xlsx files, is lack of "xl/theme/theme1.xml" > file after saving by LibreOffice Calc. This file contain style list. You are right. I had not unpacked the result, but only seen the failure. The missing theme1.xml is already tracked in bug 95057. > > I think it is too much for this bug report, and we should handle this lack > of theme for .xlsx in separate bug report. > What do you think? Yes, I agree to treat the Excel problem separately . Your patch is really fine now.
After further investigation, it seems that MS Office is opening .xlsx file perfectly fine. So definitely it is an Calc import issue. After investigating it it seems that the default imported value for Join Type was wrong (ROUND). After changing it to MITER, the file is opening correctly.
Let's move this .xlsx Join Type import to separate bug report, as I was not able to resolve it in easy way.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/606a88d2abf85aa6edcc1fa26dc50cab6de3241f%5E%21 tdf#126746 Add support for import/export line caps for .pptx format It will be available in 6.4.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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/695f6bae59de85ae2a69afc9aca5d94758ff86ed%5E%21 tdf#126746 Add support for import/export line caps for .pptx format It will be available in 6.3.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 126896 has been marked as a duplicate of this bug. ***