Bug 70841

Summary: FILESAVE: export to Excel 2003 XML (aka XMLSS) format issues
Product: LibreOffice Reporter: dg <dmitryg2002>
Component: SpreadsheetAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: normal    
Priority: low    
Version: 4.1.2.3 release   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: BSA
i915 platform: i915 features:
Attachments: example files for the bugreport

Description dg 2013-10-24 13:50:29 UTC
Created attachment 88082 [details]
example files for the bugreport

Problem description:

Export to MS Excel 2003 XML format (aka XMLSS) have following defects:
1. it writes tons on redundant data; see details below;
2. it does not format the XML with CRLF/indents; instead the output goes as two lines.

Please look at the attached files.
abc-msxlsx.xlsx is original file created in Excel Starter 2010.
abc-msxml.xml is file saved as XMLSS by Excel itself.
Now compare it with abc-msxlsx-librexml.xml, which is created by LibreOffice Calc by loading abc-msxlsx.xlsx and then saving in XMLSS. This abc-msxlsx-librexml.xml contains thousands of empty cells!
Note, if open abc-msxml.xml and save in Calc as XMLSS, then it does not have this redundancy: abc-msxml-librexml.xml
Operating System: Windows 7
Version: 4.1.2.3 release
Comment 1 Urmas 2013-10-25 05:50:31 UTC
Exporting Office XML files without line breaks is done intentionally to cause problems with Microsoft software to promote LO instead. Developers refuse to fix it.
Comment 2 dg 2013-10-25 06:27:46 UTC
(In reply to comment #1)
> Exporting Office XML files without line breaks is done intentionally to
> cause problems with Microsoft software to promote LO instead. Developers
> refuse to fix it.
kidding?
Comment 3 Urmas 2013-10-25 06:59:14 UTC
See #56943.
Comment 4 dg 2013-10-25 07:06:50 UTC
(In reply to comment #3)
> See #56943.

I see. Actually I didn't encounter with software that had parsing problems with such LO output, the only who suffers from it is myself, because it's difficult to read such documents in text editors. Remarkable that MS IE shows such XMLs in structured manner.
Comment 5 dg 2013-10-25 15:37:24 UTC
More deep analisys of the 1st problem shows that the problem might be in importing Excel xlsx files, not in exporting to XMLSS; or maybe in both. That's because if create a file in LO itself or import Excel's XMLSS, then export to XMLSS does not produce redundant empty cells.
Comment 6 mesrod 2013-12-14 17:27:04 UTC
Save .odt file as xml.  When try to open it get following:

        This XML file does not appear to have any style information associated with it. The document tree is shown below.
Comment 7 foss 2013-12-31 11:33:51 UTC
Can we have a situation update if this still behaves the same with LO 4.2.0.1?

http://www.libreoffice.org/download/pre-releases/

Should this be still reproducible for you with the latest LO release please set this bug back to UNCONFIRMED. Should this issue be solved set it to WORKSFORME.

Setting to NEEDINFO until more detail is provided.
Comment 8 Ruslan Fatakhov 2014-03-30 18:41:21 UTC
I confirm this behavior in 4.2.2.1
Comment 9 QA Administrators 2014-10-05 23:05:45 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.