Created attachment 100636 [details] xlsx file with cell borders saved by libreoffice 4.3.0 beta2 Problem description: When apply borders to cells by clicking the toolbar icon, then save as xlsx or xls format, when repened with MSO the borders are showing dashed/dotted rather than normal line borders. Steps to reproduce: 1. New spreadsheet, apply borders from the toolbar icon to some cells. 2. Save as xlsx or xls format. 3. Reopen with MSO 2010. Current behaviour: Borders are showing dashed/dotted when reopen with MSO 2010. Expected: Borders should show normal line when reopen with MSO at step 3. OS: Windows XP SP3 Reproducible in version 4.3.0 beta2, and version 4.2.5.1.
Bug 79788 and bug 79787 may be the same issue, but I reported as to saparated bugs. Adding as see also.
Created attachment 100638 [details] screenshot showing the file open with MSO 2010
Hello suokunlong, Repro with LO 4.3.0.0.beta2+ Build ID: 4b5975b1f777c85259bc38afbfae8e1160fbebbe TinderBox: Win-x86@42, Branch:libreoffice-4-3, Time: 2014-06-08_21:29:21 Windows 7 Home Premium. Set Status to New. Jacques
Alex's comment at: https://bugs.freedesktop.org/show_bug.cgi?id=75130#c31 may be the same issue as this bug, added bug 75130 to see also. Also, this bug may be caused by the fix of bug 75130.
*** Bug 82877 has been marked as a duplicate of this bug. ***
Added Kohei Yoshida to cc list, as he worked on the fix to bug 73487.
** 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 on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Created attachment 121955 [details] Example ODS for testing
Created attachment 121956 [details] Picture of the Lines LO and MS
I have testes with master build: bbfeab3b13b48c99cfa2f94c8c34bc3efef7faa9 The "Example ODS for testing" has all Lines defined, when this file save as "xlsx" and load with LO then you get following result. (The numbers of lines can be show in "Picture of Lines LO and MS") - The Linie 1 has change the Width from 3,50 to 2,50 - The Linie 2 change to Linie 1, and the Width change from 3,0 to 2,50 - The Linie 3 change to Linie 4, the Width is right (tested with: 0,75 and 1,75) - The Linie 4 change to Linie 1, and the Width change from 0,5 to 0,05. - The Linie 5 has change the Width from 1,00 to 0,75 - The Linie 6 has change the Width from 1,50 to 0,75 - The Linie 7 has change the Width from 2,00 to 2,50 In "Picture of Lines LO and MS" you can see for my opinion how convert the Lines between the LO and MS But under Excel i has not found the change of "width" is that the reason why the "width" general not work!? I would like to change the Line-Style, descript in "Picture of the Lines" is that okay?
Created attachment 122494 [details] New Mapping LO-Excel-Lines
I have made a new document look to "New Mapping LO-Excel-Lines" you can see the current mapping, and my suggestion how we can do other, what do you mean, other suggestion, or it is okay and i can change!? AND FORGET the comment:10
@Juergen: Is it not possible to extend LO's available list of line styles, so we could have a 1:1 relationship with MSO? If not, having interoperability work correctly is a good option, but what happens when an unknowing user selects one of the styles which is mapped to a different looking style and then export it to xlsx?
Created attachment 122897 [details] New Mapping LO-Excel-Lines 1.1 A new description of the mapping
Hi Yousuf (Jay) Philips, i do not change the available Line-Styles, at the moment we have and after my patch are always 7. I only change the mapping Line-Style to MS-Lines, and this mapping i descript in "New Mapping LO-Excel-Lines 1.1" At the moment i work on the Unit-Test for the mapping (the mapping is complete), now. It is arranged with the design-committee. Hope it is okay, for you
(In reply to Juergen Funk (CIB) from comment #15) > i do not change the available Line-Styles, at the moment we have and after > my patch are always 7. Yes i was aware you didnt change the line-styles, but the question was whether it was possible to do so. > I only change the mapping Line-Style to MS-Lines, and > this mapping i descript in "New Mapping LO-Excel-Lines 1.1" > At the moment i work on the Unit-Test for the mapping (the mapping is > complete), now. It is arranged with the design-committee. I have added it to the design PAD so it can be discussed this friday at the design meeting.
Hi Yousuf (Jay) Philips, i think it is a good idea, but has nothing to do with this bug. I mean a new Line-Styles are a new feature, we have 17 different BorderLineStyles look here: http://api.libreoffice.org/docs/idl/ref/namespacecom_1_1sun_1_1star_1_1table_1_1BorderLineStyle.html but for example the MS-Line Slant-DashDot is missing, and the other LineStyles not all equal to the MS-Lines, then we need new BorderLines. I'm testing now the Unit-test and want commit, it is okay for you (we need this patch as soon as possible). When we improve the BorderLineStyle then we should improve this mapping and the Unit-Test
I have push to gerrit here: https://gerrit.libreoffice.org/22665 have tested under windows, linux, the good and bad case. That is my first unit-test, hope it is okay
Maybe this older bug report is also related https://bugs.documentfoundation.org/show_bug.cgi?id=77369
(In reply to Pedro from comment #19) > Maybe this older bug report is also related > > https://bugs.documentfoundation.org/show_bug.cgi?id=77369 Nope not related as this is about compatibility and that is about functionality.
Juergen Funk committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=51737960911d41593ffd9792a6a85aeaa86824fd tdf#79787 Normal cell borders are showing dashed/dotted reopen in MSO It will be available in 5.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.
ah wow :)
*** Bug 99190 has been marked as a duplicate of this bug. ***
*** Bug 88743 has been marked as a duplicate of this bug. ***
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Hello Juergen, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
Fixed and tested
(In reply to Juergen Funk (CIB) from comment #27) Bug still exists under linux. Steps: 1. New Calc; 2. Apply border using the toolbar icon; (the border is solid) 3. Save as xlsx/xls and reopen with MSO. (the border is dashed) Version: 5.2.2.2 Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: zh-CN (zh_CN.UTF-8); Calc: group Ubuntu 16.04 LTS x64. Am I missing something?
bug repro in Version: 5.3.0.0.alpha0+ Build ID: 70c7e82003a539ed7f7ccbe596bde5ac9031d15c CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-09-23_06:53:48 Locale: ru-RU (ru_RU); Calc: group
Hi Kevin Suo, that was my first idea, you not have the right version, and of the other hand, not all mapping between LO and MS are possible, in this case you can look to the attachment "New_Mapping_LO-Excel-Lines_1.2"
Created attachment 127693 [details] New Mapping LO-Excel-Lines 1.2.ods
Hi Kevin Suo, or kompilainenn can you set the Status back to RESOLVED fixed. For me it is works
(In reply to Juergen Funk (CIB) from comment #30) As already stated in my original bug report, the bug is: When you apply borders using the default toolbar icon command, it applied a border which is solid, but after save as xlsx the border become dashed when open with MSO. The default toolbar icon command apply borders with 0.05 pt, and based on your mapping the line is EXC_LINE_HAIR in MSO. This is the problem. So, the further solution is: 1. Give the toolbar command a new value (for example, 0.75pt) which can produce a solid line when open with MSO. Or 2. Mapp 0.05 to one of the solid line type. For me it really does not matter if I apply border using the cell formatting dialog with 0.05pt and then the border becomes dashed in MSO. But, it really matters when I apply border using the toolbar and it shows me a solid border, but becomes dashed when reopen with MSO. 99% of the time people apply borders using the toolbar, not using the formatting dialog.
(In reply to Kevin Suo from comment #33) > The default toolbar icon command apply borders with 0.05 pt, and based on > your mapping the line is EXC_LINE_HAIR in MSO. This is the problem. BUT this mapping i have not changed > So, the further solution is: > 1. Give the toolbar command a new value (for example, 0.75pt) which can produce a solid line when open with MSO. > 2. Mapp 0.05 to one of the solid line type. The best solution is 1, when change the mapping in this case the roundtrip is break, that was my main point, not change always the borders between LO and MS. I think, this bug is solved, but yours is a new bug/feature, and i can not decide what for solution is the right, but i think the best and easiers is 1
(In reply to Juergen Funk (CIB) from comment #34) Yes, your patch has brought a lot of improvements to the border behaviour between ods and xlsx/xls, and thanks a lot for your hard work. But do you think the issue I mentioned in the original bug report is resolved? I don't think so. Quote from original bug report: > Problem description: > When apply borders to cells by clicking the toolbar icon, then save as xlsx or xls format, when repened with MSO the borders are showing dashed/dotted rather than normal line borders. My concern above is not a new issue.
(In reply to Kevin Suo from comment #35) > (In reply to Juergen Funk (CIB) from comment #34) > > Yes, your patch has brought a lot of improvements to the border behaviour > between ods and xlsx/xls, and thanks a lot for your hard work. > > But do you think the issue I mentioned in the original bug report is > resolved? I don't think so. > > Quote from original bug report: > > Problem description: > > When apply borders to cells by clicking the toolbar icon, then save as xlsx or xls format, when repened with MSO the borders are showing dashed/dotted rather than normal line borders. > > My concern above is not a new issue. I support this view
(In reply to kompilainenn from comment #36) > (In reply to Kevin Suo from comment #35) > I support this view The problem is when we change the mapping from LO-Line-1 0,05 to Excel-Line-6 we lost this witdh information (0,05-0,50), and this mapping was before my change. Then i prefer we change the default to 0,75. I give that to the design-team for decision, and then i hope i get a time slice for change.
(In reply to Juergen Funk (CIB) from comment #37) > I give that to the design-team for decision, and then i hope i get a time slice for change. How can we ping the design-team?
(In reply to Kevin Suo from comment #38) > (In reply to Juergen Funk (CIB) from comment #37) > > > I give that to the design-team for decision, and then i hope i get a time slice for change. > > How can we ping the design-team? IRC-channel #libreoffice-design on Freenode.net
(In reply to Kevin Suo from comment #38) > How can we ping the design-team? Keyword needsUXEval is set and ux-advice is CC'ed so the design team is aware of this ticket. To summarize: aiming for compatibility with MSO the options are 1) change the predefined border size from 0.05 to 0.75 2) map hairlines to something else, I guess that means to save/export 0.05 in a different style Solution 1) sounds very simple, and users can change the line width back to 0.05 - ending up in the same trouble but intentionally in this case. Probably I do not understand 2 but isn't this the best solution?
> 1) change the predefined border size from 0.05 to 0.75 Please, before we discuss changing the default line thickness to something else, try *printing* a table with some text in it with the two different line thicknesses (Please do print, as you won't see much difference on the screen). * 0.05 * 0.75 I did that and I would very much prefer sticking with the 0.05. The 0.75 line is much thicker and makes reading the text in the table harder. I know that you can always change it back, but most users will stick with the default line thickness. Also note that the roundtrip LO -> xlsx -> LO works fine. The problem is only when opening it in Excel. We definitely need to live with some differences here, since the line styles in Excel differ quite a lot from the ones in Calc. Attachment 127693 [details] has all the details.
(In reply to Samuel Mehrbrodt (CIB) from comment #41) > We definitely need to live with some differences here... Solution 3): WONTFIX (sounds good to me too).
(In reply to Heiko Tietze from comment #42) > (In reply to Samuel Mehrbrodt (CIB) from comment #41) > > We definitely need to live with some differences here... > > Solution 3): WONTFIX (sounds good to me too). This is not good idea. That can say about all bugs in bugzilla. I think, need resolve with different style of border line.
We had similar discussions of what should be the default border line width for tables in bug 99027. So if we check out the competition, all of them (Excel, WPS/Kingsoft, Google Sheets, Gnumeric, Calligra Sheets, Quattro Pro) provide style presets that combine both the border line style and width. Calligra Sheets is the only one that allows a user to create a custom style and width, but limits the width to being only whole numbers. (In reply to Juergen Funk (CIB) from comment #37) > The problem is when we change the mapping from LO-Line-1 0,05 to > Excel-Line-6 we lost this witdh information (0,05-0,50), and this mapping > was before my change. That is only natural because of format differences. When excel exports its default border to ods, Calc opens it up at 0.05 and Calligra opens it at 1. > Then i prefer we change the default to 0,75. I would agree with this to provide maximum compatibility. (In reply to Samuel Mehrbrodt (CIB) from comment #41) > Please, before we discuss changing the default line thickness to something > else, try *printing* a table with some text in it with the two different > line thicknesses (Please do print, as you won't see much difference on the > screen). Yes someone with a printer should print out a sheet with various border widths and give a recommendation of what they think should be default. I'd recommend testing in 0.25 increments.
*** Bug 79788 has been marked as a duplicate of this bug. ***
Added to XLSX format limitation in bug 88175
So in bug 99027, we've decided to go with 0.50.
** 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
Created attachment 147080 [details] Comparison LO 6.2 vs MS Excel 2010
bug still repro in Version: 6.2.0.0.beta1 Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
*** Bug 135957 has been marked as a duplicate of this bug. ***
Created attachment 169205 [details] Screenshots of both files opened on Excel I would like to share a brief experiment I did to explain why I think the compatibility of borders between Calc and Excel can be improved. What I did is: 1) I created a file on Calc (ODS) with a table formatted with the default borders. I saved it as ODS (see file Border_Test.ods attached) 2) Then I exported the ODS file to XLSX (see file Border_Test.xlsx attached) 3) I opened the exported XLSX file on Excel and the border is dashed/dotted 4) I opened the ODS file on Excel (Office 365 can open ODS files) and the borders were normal, as expected. I attached a file Border_Calc_Excel.odg with screenshots from steps 3 and 4. If Excel can open an ODS file and convert border information as expected, than I believe that it is possible to have Calc save the XLSX file in a way that the border won't appear dashed on Excel. I had the same results using both LO 7.0.4.2 and 7.2 alpha (daily builds). I'd like to point out that this is a major compatibility issue between Calc and Excel. Anyone formatting their tables with default borders on Calc and saving as XSLX will experience this problem. I use Calc in my lectures all the time and then, when I export to XSLX, I have to fix all my borders manually before sending the files to anyone. Fixing this bug will be a great contribution to the compatibility between ODS and XLSX files.
Created attachment 169206 [details] Original ODS file created on Calc
Created attachment 169207 [details] Exported XLSX file
Created attachment 169481 [details] Test with Line Styles I made a macro that formats cells with each line style available in LibreOffice. The macro and the formatted output can be seen in Line_Styles.ods inside the ZIP file I've just attached. Then I saved the ODS file as XLSX and opened it in Office 365. Unfortunately almost none of the line styles were correct. Only styles 14 and 15 were exported correctly. The remaining styles were all incorrect. The exported file is Line_Styles.xlsx and it is available in the attached ZIP file. I also made an ODG file with screenshots of both results for a better comparison. In summary, there seems to be a generalized issue in the XLSX export filter with respect to line styles.
Created attachment 180265 [details] Screenshot as of LO 7.3 It seems this issue has been fixed since 7.3. Reproducing the steps from Kevin Suo will result in solid borders both in Excel and Calc. This is good news, however this fix raised an inconsistency in border weights, which has been reported in Bug 149208. In summary, the way LO Calc draws the borders in the screen make them look excessively thick. IMO this bug could be closed as WORKSFORME since no patch was directly associated with it and the bug no longer occurs.