Created attachment 133528 [details] Example file from LO 5.3 The Border Line Style property of the data series is not preserved when the file saved as DOCX in LibrOffice Writer. Steps to reproduce: 1. Create an empty text document in LibreOffice Writer 2. Insert a Chart 3. Change the Data Series Border Line Style property to something other than none or Continuous (such as Ultrafine Dashed). 4. Save the file as DOCX 5. Reopen the file either in LibreOffice Writer or Microsoft Word 2013 Actual results: The border around the data series appears as a continuous line. Expected results: The border should appear as intended (e.g. Ultrafine Dashed).
Created attachment 133529 [details] Example file saved from LO 5.3
Created attachment 133530 [details] Docx in Word 2013 and odt in LO 5.3 side by side
Hello Gabor, I reproduce with LO 5.5.0.0.alpha0+ Build ID: 0e6297932252403883a6057feee488e4ee2bc360 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-23_00:14:17 Locale: fr-FR (fr_FR); Calc: CL and LO 4.2.0.0.beta1 Build ID: f4ca7b35f580827ad2c69ea6d29f7c9b48ebbac7 & Windows 7 Home
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reproduced also with LO 6.1.0.0.alpha1+ Build ID: 23c5125148a8110d88385b29570bf0b7d4400458 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-05-12_00:15:25 Locale: fr-FR (fr_FR); Calc: CL
Hello! I've noticed that if you make the docx file with MS Word, inside the unzipped docx folder in the chart1.xml file there are a tag something like: <a:prstDash val="dash"/> or <a:prstDash val="sysDot"/> or <a:prstDash val="lgDashDotDot"/>. The value of val="something" certainly depends on the custom line style you chose (for example sysdot is also like normal dashes, and lgDashDotDot contains more than one dashes and dots). When you save the docx file with LibreOffice Writer, this a:prstdash tag will be removed and there will be an <a:custDash/> tag instead of it/them (without val="something"). If you save the file with LibreOffice Writer (...then it loses the custom line style of course...) and manually edit the chart1.xml file, and delete the <a:custDash/> tag, and instert an appropriate tag (for example a <a:prstDash val="dash"/>) instead of it, rezip the contents of the folder and rename it to docx, the custom line style will work again, and it will have the same look (I havent tried all of the custom styles, just a few one). (You can check out and edit the xml files with xml copy or open xml sdk. Open xml sdk can also compare two xml files). I guess the responsible code for this, is in the WriteOutLine function in the https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx#573 file, starting at the line 700, with this: if( bDashSet && aStyleLineStyle != drawing::LineStyle_DASH ). Currently I have no idea how to solve it. I tried to rename XML_custdash macros to XML_prstDash, but thats not working. I also tried to delete the else block and the if header, and the result was losing the custom dash property, but the line style wont be continous, instead of it it will be dashed with long dashes and long spacing. Can somebody help? :)
This could be useful about the prst (preset) dashes: http://officeopenxml.com/drwSp-outline.php
About the custom line styles: https://msdn.microsoft.com/en-us/library/dd947967(v=office.12).aspx
Reproducible also Version: 6.0.5.2 Build ID: 1:6.0.5~rc2-0ubuntu0.16.04.1~lo1 CPU threads: 2; OS: Linux 4.10; UI render: default; VCL: gtk2; Locale: id-ID (id_ID.UTF-8); Calc: group Ubuntu 16.04.5
Can be also useful: https://docs.microsoft.com/en-us/dotnet/api/documentformat.openxml.drawing.presetlinedashvalues?view=openxml-2.8.1
https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx https://opengrok.libreoffice.org/xref/core/oox/inc/drawingml/lineproperties.hxx https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/drawing/LineProperties.idl
So in the file: https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx There are some settings for the preset line styles in this function: https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx#62 And the meanings of the numbers can be seen in this function: https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx#lclSetDashData For example XML_dot: 1, 1, 0, 0, 3, and the meanings: Dots, DotLe, Dashes, DashLen, Distance. I guess some if-else-if should be written in this function: https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx#573 around line 704.
One question. Why are these properties in if-else relation? If something has a color property it cant have a linestyle property? if (aStyleProperties.hasElements()) 619 { 620 for (sal_Int32 i=0; i < aStyleProperties.getLength(); ++i) 621 { 622 if( aStyleProperties[i].Name == "Color" ) 623 aStyleProperties[i].Value >>= nStyleColor; 624 else if( aStyleProperties[i].Name == "LineStyle" ) 625 aStyleProperties[i].Value >>= aStyleLineStyle; 626 else if( aStyleProperties[i].Name == "LineJoint" ) 627 aStyleProperties[i].Value >>= aStyleLineJoint; 628 else if( aStyleProperties[i].Name == "LineWidth" ) 629 aStyleProperties[i].Value >>= nStyleLineWidth; 630 } 631 }
(In reply to Adam Kovacs from comment #13) Ok, I understand it. This is in a loop, and in one step there can be only one property validated.
Unfortunately this code is not working. The control only gets to the else branch. Such like if aLineDash doesn't even initialized. //XML_dot if (aLineDash.Dots == 1 && aLineDash.DotLen == 1 && aLineDash.Dashes == 0 && aLineDash.DashLen == 0 && aLineDash.Distance == 3) { mpFS->singleElementNS(XML_a, XML_prstDash, XML_val, "dot", FSEND); //XML_dash } else if (aLineDash.Dots == 0 && aLineDash.DotLen == 0 && aLineDash.Dashes == 1 && aLineDash.DashLen == 4 && aLineDash.Distance == 3) { mpFS->singleElementNS(XML_a, XML_prstDash, XML_val, "dash", FSEND); //XML_dashDot } else if (aLineDash.Dots == 1 && aLineDash.DotLen == 1 && aLineDash.Dashes == 1 && aLineDash.DashLen == 4 && aLineDash.Distance == 3) { mpFS->singleElementNS(XML_a, XML_prstDash, XML_val, "dashDot", FSEND); } //...and so on
There was a commit for this, but the message accidentally omitted the # from tdf#, so there was no automated comment & whiteboard: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f5f235051055d24c8aced602078c54261603efea Are further commits coming or is this done?
It is planned :)
Adam Kovacs committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3d6c44c9cb533fe4f1cd28fc95adc36cac4bfd5 tdf#108064 OOXML export: keep preset dashes with any line width It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Adam Kovacs committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=761308edb65a6cf44ef84cebc387e77af8b70f83 tdf#108064 OOXML export: fixing linestyle export in charts It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Adam Kovacs committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5cc52fec12e3c8d1c3561f172d3e1c5434290b3 tdf#108064 OOXML export: keep preset dashes with mso preset linewidths It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Started in 4.2. Previously, chart couldn't be open with MSO.
Adam Kovacs committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=47c3b0390e5ad5a894488c47f014cdd7ecba7d2e tdf#108064 OOXML export: convert LO preset dashes to equivalent MSO presets It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 145545 [details] test file converted from ODT to DOCX by Word 2016 This was marked fixed, but we could do a better job matching LO's fine dash to MSO's "round dot" dash type. It's not perfect, but it's a much closer match. Attached an example to show how the OOXML looks like.
Created attachment 145557 [details] In my latest commit there is a conversion in the case of LO preset dashes, which has equivalent MSO preset dashes Related to this commit: https://gerrit.libreoffice.org/#/c/61417/
Created attachment 145558 [details] mso vs lo preset dashes
Created attachment 145559 [details] MSO preset dashes with names
Created attachment 145560 [details] MSO preset dashes example
Created attachment 145562 [details] Lineproperties of LO preset dashes
(In reply to Luke from comment #23) > Created attachment 145545 [details] > test file converted from ODT to DOCX by Word 2016 > > This was marked fixed, but we could do a better job matching LO's fine dash > to MSO's "round dot" dash type. It's not perfect, but it's a much closer > match. > > Attached an example to show how the OOXML looks like. Now you can try with my new fix. 7 of the 10 LO preset dashes should be working (which have MSO preset dash equivalents).
(In reply to Adam Kovacs from comment #29) > (In reply to Luke from comment #23) > > Created attachment 145545 [details] > > test file converted from ODT to DOCX by Word 2016 > > > > This was marked fixed, but we could do a better job matching LO's fine dash > > to MSO's "round dot" dash type. It's not perfect, but it's a much closer > > match. > > > > Attached an example to show how the OOXML looks like. > > Now you can try with my new fix. 7 of the 10 LO preset dashes should be > working (which have MSO preset dash equivalents). Adding Luke to CC to notify
Adam, In Word, if you open your 'lo_preset_all.odt' and save as .docx, and edit the xml, you will see that the LO preset "Ultra fine dash" used in this bug report is not converted to one of MSO's presets. Rather they use a custom dash, producing better results. Here is the OOXML generated by Word: <a:custDash> <a:ds sp="33611" d="33611"/> <a:ds sp="33611" d="33611"/> </a:custDash> Here is the OOXML generated by Writer <a:prstDash val="sysDot"/> <a:round/> </a:ln> I thought you might be interested to see how Word handled it with a custom dash. I did not mean to nitpick. You've done a great job here. Thank you!
(In reply to Luke from comment #31) > Adam, > > In Word, if you open your 'lo_preset_all.odt' and save as .docx, and edit > the xml, you will see that the LO preset "Ultra fine dash" used in this bug > report is not converted to one of MSO's presets. Rather they use a custom > dash, producing better results. > > Here is the OOXML generated by Word: > <a:custDash> > <a:ds sp="33611" d="33611"/> > <a:ds sp="33611" d="33611"/> > </a:custDash> > > Here is the OOXML generated by Writer > <a:prstDash val="sysDot"/> > <a:round/> > </a:ln> > > I thought you might be interested to see how Word handled it with a custom > dash. I did not mean to nitpick. You've done a great job here. Thank you! So you make an ultrafine LO preset dash into an odt file, open it with World, and save it to docx? I guess that's good as long as you don't open it with Writer :)
*** Bug 94336 has been marked as a duplicate of this bug. ***
(In reply to Adam Kovacs from comment #32) > (In reply to Luke from comment #31) I guess that's good as long as you don't open it > with Writer :) Why? Writer has no issue opening attachment 145545 [details]. The custom dash that Word uses to convert 'Ultrafine Dashed', is a close approximation to our preset. It can be opened by both Writer and Word.
Created attachment 145618 [details] ultrafine dash odt to docx converted by msword
Created attachment 145627 [details] Word 2016 converted Ultra Dash, opened correctly in Writer Adam, This is strange. I get different results than you. Are you running an updated version of word 2016?
Created attachment 145628 [details] LO Ultrafine Dashed converted by Word 2016
Version 1708 (build: 8431.2236)
Adam Kovacs committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba60a132e788201d4074c576352b4f462c16a9c6 tdf#108064 OOXML export: keep preset dashes with linewidth < 1pt It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 148509 [details] MSO preset dash names MSO preset dash names: 1: sysDot 2: sysDash 3: dash 4: dashDot 5: lgDash 6: lgDashDot 7: lgDashDotDot There are 3 more in OOXML standard: dot, sysDashDot, sysDashDotDot You can put these 3 into OOXML, but in MSO, they are not changable from the list. Some LibreOffice preset dashes converted to these: "Fine Dotted" -> dot "2 Dots 1 Dash" -> sysDashDotDot