Problem exporting to XLS format

Hi there,

I’ve been trying to export a spreadsheed from Libreoffice Calc to XLS Excel compatible format and what happens is kinda weird.

I usually setup the environment to work with less swap memory than usual. The first two or three times I tried this conversion, the system froze after something about 30 minutes (I realized something was wrong and was trying to trace the problem). So I set the swappiness to 100% and tried again. The system got unstable but did not froze and I could trace the whole process.

After a few minutes the progress bar stalls and memory usage (RAM and SWAP) and processor load ramp up to 100%. At some point Calc saves a .tmp file on disk of about ~650MB in size and crashes. The spreadsheet I’m working on contains 13 sheets and 1 simple chart. Nothing much.

Setup:
OS: Linux x64 6.1.25-1-MANJARO
Processor: Athlon II x2 250 3.0GHz
RAM: 8GB RAM
Libreoffice: 7.5.2.2 50(Build:2)

Here is an output from BPyTop after a few minutes:

Maybe there is some memory leak, not sure.

Thank you.

Compatible with what? ODF is the standard. Excel can read and write Open Document Spreadsheets (*.ods).

1 Like

I’ve been trying to open .ods spreadsheets on other office suites and there is always a problem here and there. So I read online I should try to to export from Calc to .xls and open it on OnlyOffice or FreeOffice from that format.

Thank you.

Why you think if the conversion gives you a perfect result?
Note: there is not (never was and never willbe)100% compatibility between the different file formats. (Not only between the office suites, read: between the file formats.)

Use the ODF file formats. It is the only one real international standard for the documents created with the office suites.

1 Like

If at all you should not save to the old binary .xls but OOXML .xlsx
The crash likely is because all RAM+Swap is consumed and the operating system kills the process. Why the high memory consumption can’t be answered without the actual file in question, depends on content, a temporary file of 650MB is very much for a .xls file.

1 Like

Thank you all for your answers, but I think I couldn’t make my point:

I could be a footbal player, an actor, a firefighter, a surfer, a singer, an mma fighter, a comedian, whatever… Even someone who had never touched a computer before.

I could be a Windows user or have a mainframe at my disposal and everything would be fine, but that is not the point. It is not about solving “my problem” doing this or that. I’m rebuilding my spreadsheet from scratch on other office suites and that’s totally fine. No big deal.

The point is: there is a problem in Calc and that is still there. Some users can’t export directly to XLS format. If users are not desired to export their spreadsheet to XLS binaries, maybe this option should not be there.

That’s why we report bugs or unexpected behavior, so the developers can look into those, fix those and improve the quality and UX of their software, right?

That’s what I was looking for.

Thank you. :slight_smile:

This is a user group, bugs aren’t reported here, see This is the guide - How to use the Ask site? - #3 by Hrbrgr and How to Report Bugs in LibreOffice - The Document Foundation Wiki

Maybe it is an issue with your setup. Does it work OK in LibreOffice Safe Mode, Help > Restart in Safe > Continue in Safe Mode?

1 Like

This is a user group, bugs aren’t reported here, see This is the guide - How to use the Ask site? - #3 by Hrbrgr and How to Report Bugs in LibreOffice - The Document Foundation Wiki

My bad.

Maybe it is an issue with your setup. Does it work OK in LibreOffice Safe Mode, Help > Restart in Safe > Continue in Safe Mode?

I’m not sure. I’ll try it and report here when I can.

Thank you.

By the way, I’m not sure I can agree with you on that because OnlyOffice messes everything on that spreadsheet, by the other hand FreeOffice’s PlanMaker reads that almost flawlessly.

Same file.

Thank you.

No. Same behaviour.

Thanks.

It works for a lot of users, so no need to hide a usable tool because of lack of perfection.
.
The main point - also for your bug-report - is: Can you share your file, so one can try to find out, why it crashes? If it contains private data, can you replace that with non readable stuff?
.
IMHO Calc should not crash on exporting a file… Question is, why so much memory is necessary.

How is this related? You are told, that there are fundamental differences in document formats, that prevent preserving 100% fidelity in some features when converting between formats. This is a general information, a fact of truth; how it relates to your specific case is unknown to anybody who didn’t see your file (i.e., to anyone here except yourself).

Possibly you disagreed with the final statement, that “ODF is only one real international standard for the documents created with the office suites”? Well of course, this is not correct, and is very personal and polarizing opinion. OOXML is also an international standard; their upsides and downsides, their history of rivalry is very politized … But the correct advise would be: always use the native file format for any given software you use, to preserve 100% of what it can represent, if only possible. And export to external file formats only if unavoidable, to transfer to others, keeping the native file as the primary document.

There is always some baseline that anyone has to know to communicate with others and with environment. You can’t avoid learning your language. If one can’t read, they won’t be able to enjoy the same ease of life as those who can. If one can’t count, … So yes, there are special things that could make lives of people who “never touched a computer before” problematic when they touch it the first time. And in your ideal world, there is only one office suite, and other imaginary suites are 100% clones. You don’t allow any developer to think they know a better way of doing the same task, and creating their tools to give people a chance to use a different paradigm - which (unfortunately for some) means that there’s some difference that needs to be learned…