SheetJSDev
commented
10 years ago Try writing with the shared string table (bookSST:true option when you write).
I explored Excel 2011 a bit and found:
1) Shared strings table parser apparently treat both forms of newline (literal \n as well as the escaped x000d) as new lines
2) Inline strings parser ignores the literal newline and only process the x000d encoded newline
3) Shared strings parser assumes whitespace is preserved and inline strings parser assumes whitespace is not preserved. The xml:space="preserve" attribute is completely ignored in both cases.
You'd think that Excel would use one unified XML parser, but it appears that is not the case :/ The fix here is straightforward, but the question still remains: should the writer handle both types of newline (\n and \r\n)? A literal encoding of both in the shared string table is treated as two newlines, not one, so there is some ambiguity there
tophsic
reviewher
lumio
qqilihq
zaddok
fozcode
jefleponot
lukaselmer
GusMartins499
jdegger
binaryn3xus
kentmor
KrunchMuffin
vfa-tanna
When values
vof cells contain unix line endings\nthey do not become line breaks in the corresponding cells of the written workbook. However, when the Windows carriage return newline combos\r\nare used Excel appears to properly break the lines when a cell containing them is double clicked (edited).So there appear to be two things to potentially address here:
\ndo not become new lines at all in the written file\r\nonly become newlines in Excel when the cell is edited. This may be a shortfall in Excel for Mac 2011 and may not apply to the Windows version.