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.
Simply not seeing an issue when saved as OOXML and opening with MS Word.
MS Word 2007
MS Office365 Excel on-line
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.
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)
Created attachment 117472 [details]
This file will show A over B in Calc and "AB" in Excel
For the comment above, I meant (The "A" is default") not (The "A" is italic")
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.
Migrating Whiteboard tags to Keywords: (filter:xlsx)
** 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.1.6 or 5.2.3 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
If 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)
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 helping us make LibreOffice even better for everyone!
So Calc exports it like this
and Excel exports it like this
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 B</t>
So this has been resolved with latest master if you open attachment 117472 [details] and save it and then open it in Excel.
Build ID: 34c77d4bf3d2924c4ad26728d4c491b393fa0fc8
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); Calc: group