Microsoft Excel does not understand the number-columns-repeated attribute. For exmaple: <table:covered-table-cell table:number-columns-repeated="3"/> will only produce one covered cell. Instead, Excel 2010 emits and understands: <table:covered-table-cell/><table:covered-table-cell/><table:covered-table-cell/> This applies to other elements too: <table:table-column table:style-name="co1" table:default-cell-style-name="ce1" table:number-columns-repeated="3"/> is not understood, and requires changing to: <table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/><table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/><table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/> I think Excel compatability should be a higher priority than file size. Please change the FILESAVE code to emit repeated elements instead of using the number-columns-repeated attribute.
Once bug #53998 is implemented, the number-columns-repeated attribute can be re-introduced on the 'pure' codepath.
I meant to add in the original bug description that this also applies to the number-rows-repeated attribute too.
Compatibility to Excel2010 is not important. Excel2010 is not even able to read the formulas so using ODF as exchange format with Excel is useless anyway. Please check if this is still an issue with Excel2013 but even then I think that we should not change this for a bug in another product. We are already having enough problems with the Microsoft formats should concentrate on ODf compatibility and how our odf output works with other odf consumers.
(In reply to comment #3) > I think that we should not change this for a bug in another product. Could you mark this bug as WONTFIX then?
CCing as seems you are not on the CC list to notice a request.
Another reason to prefer <table:covered-table-cell/><table:covered-table-cell/><table:covered-table-cell/> over <table:covered-table-cell table:number-columns-repeated="3"/> is that it compresses better, resulting in smaller file sizes for zlib-compressed saves.
(In reply to comment #3) > Compatibility to Excel2010 is not important. I am trying to encourage ODS usage in an office where Excel 2010 is ubiquitous. I cannot send raw LO-exported files to my colleagues without first decompressing them, editing the file so that it uses syntax that Excel supports, and the recompressing them. Surely I am not alone in trying to use free software in a Microsoft-dominated environment, though I may well be alone in hand-editing the XML! Is it not a goal of yours (plural) to gain adoption of your product in a commercial surrounding? I believe anything that can ease the migration between the market leader and your own product, especially when such actions are of so little cost in terms of time, and have no detrimental effects, should be done.
*** Bug 53998 has been marked as a duplicate of this bug. ***
We should not cater for other applications' bugs in our native file format. Besides, Excel 2013 reads table:number-columns-repeated attribute fine.