1) On a round trip from Microsoft Excel to LibreOffice Calc to Microsoft Excel formatting data is lost. Also the end of table marker is not displayed in LibreOffice Calc.
2) When a row of data is added in LibreOffice Calc, and the saved document re-opened in Microsoft Excel the formatting is still missing, and the end of table marker has not moved as it would have if the row of data had been added in Microsoft Excel.
Steps to Reproduce:
1) Open a new blank xlsx document. Microsoft Excel 2013 on a Windows 10 PC used.
2) Create a table of data using multiple rows and columns. The first row being the table header information.
3) Select all of the entered data in the spreadsheet, including the header rows. This is A1:C4 in the attached example "excel_with_table_example.xlsx" document.
4) On the HOME tab click in the "Styles" section on the "Format as Table" icon.
5) In the "Format As Table" pop-up dialogue box that opens tick the "My table has headers" box and then press ok. Notice in the bottom right corner of cell C4 the small blue "L" that marks the end of the table.
6) Open the document in LibreOffice Calc 22.214.171.124. All of the table formating will have been lost, or is not being displayed. The filter "drop-down arrows" in the table header row are still present and can be correctly used to sort the table data. The small blue "L" that marks the end of the table cannot be seen in bottom right corner of cell C4.
7) Add another row of data to the table and save the document in its original xlsx format. This is the attached "excel_with_table_example_after_calc_edit_and_save.xlsx" document.
8) Now re-open the modified document in Microsoft Excel. The original Microsoft Excel formatting is missing. The small blue "L" that marks the end of the table is in the bottom right corner of cell C4, it should now be in cell C5. This is what would have happened if another row of data had been added in Microsoft Excel. The filter "drop-down arrows" in the table header row are still present and can be correctly used to sort the table.
The key issue is that LibreOffice Calc loses the Microsoft Excel table formatting on the round trip. I don't know if Calc loses it when reading the file, or just can't display it and then fails to write it into the saved document.
A secondary issue is that the small blue "L" in the bottom right corner of C4 that marks the end of the table is not displayed in LibreOffice Calc. On adding the extra row of data in Libreoffice Calc it should have been moved to cell C5. This is what would have happened if another row of data was added in Microsoft Excel.
I will also attach a "excel_with_table_example_screenshots.pdf" showing some screenshots.
Formatting data preserved on the round trip from Microsoft Excel to LibreOffice Calc to Microsoft Excel.
User Profile Reset: No
I will attach the two excel files referred to in the "Steps to Reproduce" section and the pdf document referred to in the "Actual Results" section.
Created attachment 180543 [details]
Original document created in Microsoft Excel
Created attachment 180544 [details]
Document after save from LibreOffice Calc
Created attachment 180545 [details]
Please search before reporting. It's a well known bug for which there's no volunteer to fix.
*** This bug has been marked as a duplicate of bug 66377 ***
From an end user point of view I believe this issue is different to the bug 66377 you have marked this a duplicate of.
I was reporting formatting that is lost on a round trip to Microsoft Excel and back again, which is a compatibility issue. To me as an end user that is different to a request for a new feature that is in the description for bug 66377, whch you marked this as a duplicate of.
I understand from a developer point of view you may class them as the same.
I did run a search and not find anything matching the "end user" issue. Perhaps you would consider updating the description in bug 66377 to avoid anyone else raising the issue?
I added what I considered as needed. I don't know what to add more.
LO simply doesn't understand Table Style on open and any further saving is expectedly wrong.