Bug 92961 - FILESAVE: XLSX - New line doesnt import correctly into Excel when text has multiple direct formatting parts
Summary: FILESAVE: XLSX - New line doesnt import correctly into Excel when text has mu...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.4.3 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: interoperability
Keywords: filter:xlsx
Depends on:
Blocks: Cell-Direct-Formatting-Parts XLSX
  Show dependency tree / graph
 
Reported: 2015-07-27 13:48 UTC by Andrei B.
Modified: 2017-07-02 23:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
This file will show A over B in Calc and "AB" in Excel (4.61 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2015-07-27 15:52 UTC, Andrei B. 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei B. 2015-07-27 13:48:30 UTC 
When doing CTRL+ENTER to create a new line in a Calc cell, the separator used is '\n', and not '\r\n' specific to Windows.
After saving as .xlsx and opening in Excel, the cell content is displayed as single line, whereas in Calc it is displayed as multi line.

Best!
Andrei
Comment 1 V Stuart Foote 2015-07-27 15:32:28 UTC 
Simply not seeing an issue when saved as OOXML and opening with MS Word.

MS Word 2007
MS Office365 Excel on-line

LODev 5.1.0alpha1+
LO 5.0.0rc3
LO 4.4.4.3

When opened in MS Word 2007 the Wrap attribute is set for the spreadsheet. If not set, the cell does not wrap. So a MS Office configuration issue?

Also note that the MS Office365 the OneDrive preview for Excel opening does not wrap the cell content, but when "edited" the cell text with <Ctrl>+<Enter> are correctly wrapped.
Comment 2 Andrei B. 2015-07-27 15:51:30 UTC 
It seems there's an extra detail to reproduce the issue, the content of the cell must be "rich text".

Steps to reproduce:
1. Open Calc
2. Enter value "A" in a cell
3. In the same cell do a line break with Ctrl+Enter
4. Enter value "B" . Make the "B" BOLD (The "A" is italic")
5. Save the file as xlsx
6. Open with Excel -> BUG -> A and B are shown on the same line (it's not related to WRAPPING)
Comment 3 Andrei B. 2015-07-27 15:52:02 UTC 
Created attachment 117472 [details]
This file will show A over B in Calc and "AB" in Excel
Comment 4 Andrei B. 2015-07-27 15:53:18 UTC 
For the comment above, I meant (The "A" is default") not (The "A" is italic")
Comment 5 V Stuart Foote 2015-07-27 16:09:08 UTC 
Yep, when the text in the cell is directly formatted, the exported OOXML is not rendered correctly by MS Office Excel. 

So guess there is an export to OOXML filter issue for formatted text.

If direct formatting is removed from the cell, with <Ctrl>+M, the cells honor the line break on MS Excel.
Comment 6 Robinson Tryon (qubit) 2015-12-09 16:52:01 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2017-01-03 19:40:28 UTC Comment hidden (obsolete)
Comment 8 Yousuf Philips (jay) (retired) 2017-07-02 22:24:36 UTC 
So Calc exports it like this

<r><t>A&#10;</t></r>

and Excel exports it like this

<r><t xml:space="preserve">A
</t></r>

where the binary character of 0x0A was after the A.

So the problem turns out to be the missing xml:space attribute of the <t> tag.

(In reply to V Stuart Foote from comment #5)
> If direct formatting is removed from the cell, with <Ctrl>+M, the cells
> honor the line break on MS Excel.

Yes it is exported correctly in this case, as it did add the xml:space attribute.

<t xml:space="preserve">A&#10;B</t>
Comment 9 Yousuf Philips (jay) (retired) 2017-07-02 23:19:01 UTC 
So this has been resolved with latest master if you open attachment 117472 [details] and save it and then open it in Excel.

Version: 6.0.0.0.alpha0+
Build ID: 34c77d4bf3d2924c4ad26728d4c491b393fa0fc8
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group