Is there a risk eliminating table:number-rows-repeated attribute

users
#1

Hello list,

My question is quite technical, but I hope I will have an answer. I need it very badly... :-

On some documents (Excel .xls) I wish to convert to "Microsoft Excel 2003 XML" I have exactly this bug: https://bugs.freedesktop.org/show_bug.cgi?id=52035

Doing some research, I found out I can make it work if I:
1. convert the document to ODS
2. unzip the ODS
3. run the attached XSLT on "content.xml"
4. zip it back, open it, save it as "Microsoft Excel 2003 XML"

The xslt remove any "table:number-rows-repeated" attributes.

So my question is:

By doing what I describe in this procedure is there a risk to break the content of the file or to make the file not a valid ODS file?

Thanks a lot!

Maxime Bégnis

#2

Hello, thanks for your answer.:slight_smile:

We have a script and some XSLT to do indeed funny things, and it would be easier for us to keep it as it is. However, dealing directly with ODS format to extract what we need from the file would be less tricky of course, but it would be much more work. Anyway, doing what you suggest might save us some time and troubles in the end...

Cheers,

Maxime Bégnis

#3

Hi :slight_smile:
Do you really have to have it in that format? Straight Xls is easier!
XlsX and Ods are both Xml formats.

If it has to be Xml to allow some scripts to do funny things to it
then perhaps Ods itself might be valid?
Regards from
Tom :slight_smile:

#4

Hi :slight_smile:
The format your script is currently written for is more stable than
the more recent MS formats such as XlsX. Ods is far more stable for
the future and even MS Office 2013 & 365 can use it.

Unfortunately MS Office 2010 and earlier can't handle Ods due to MS's
bad implementation. Prior to 2013 they replaced all formulae with
just the value that happened to be in each one at the time. However
it sounds like your company might still be largely on MSO 2003 or
earlier which is kinda helpful for once.

So they might have 3 ways to upgrade for the future
1. Rewrite the script for XlsX only and hope that the changes in that
format between different versions of MSO are not enough to break the
script
2. Rewrite for both XlsX and Ods so that everyone's happy (ie when
'one' format breaks one script (naming no names) then the other is
available and still working
3. Rewrite for just Ods. Sadly this best option is the least likely
4. No re-write and then over the years watch everything fall apart as
MS start to withdraw support for their older versions

I'm still wondering if Regina or Brian or someone has a better answer
that does work in the format you really need in the here&now!
Regards from
Tom :slight_smile:

#5

"Maxime Bégnis":

The xslt remove any "table:number-rows-repeated" attributes.

So my question is:

By doing what I describe in this procedure is there a risk to break the
content of the file or to make the file not a valid ODS file?

There is no other way to represent empty rows in ODF tables except explicitly declaring N empty rows; so your idea won't work.

#6

Thanks for your input. Indeed it does not work, as we found out. We now convert to ODS flat XML before extracting the data. It seems to be much more reliable.

#7

Hi :slight_smile:
Nice work Urmas! :slight_smile: Congrats to Maxime too :slight_smile:

It might be possible to set "ODS flat XML" (=fods?) as the default file-type

Tools - Options - Load/Save - General

Change the 1st drop-down to Spreadsheet and the 2nd one to about 4 or
5 further down the list. If you do go that way you might want to
switch off the automatic pop-up that warns you abut not using native
formats. On the other hand keeping it makes it easier to cope with
saving other documents into ods

I get the impression doing this to 1 or maybe 2 machines in the
department might be good but doing it to all might be a nightmare.
Regards from
Tom :slight_smile: