This is about issues where the version of LibO (and the OS?) can be very important.
There was the possibly related bug tdf#121260 (alraedy mentioned by
@MassimoMula. It got a last fix with V7.3.0.
Is your version V7.3 or higher? Otherwise try an upgrade.
The other possibly related bug tdf#85328, already mentioned by myself was reported to still be open for V7.6.0.alpha.
What are your current versions?
Version: 7.5.6.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 2; OS: Linux 6.4; UI render: default; VCL: x11
Locale: en-AU (en_AU.UTF-8); UI: en-US
Debian package version: 4:7.5.6-1
Calc: threaded
tdf#85328 is undoubtedly the bug behind the chart data loss, but perhaps it’s worth opening a new one about this behaviour where using Save on an .ods spreadsheet prepared with an earlier version of Calc saves a Flat XML ODS version over the existing .ods rather than using a .fods extension to mark it visibly as Flat XML.
I have found another way to make Calc save a spreadsheet that looks like it’s in ODS format when it’s actually in Flat XML ODS format.
Steps to reproduce:
-
Use a Linux-based desktop file browser to create a new empty file named test.ods.
-
Double-click test.ods. If LibreOffice Calc is your installation’s default handler for .ods files, Calc will open it.
-
Enter some data, then choose File->Save or hit Ctrl-S. Calc will save your data as test.ods.
-
Quit Calc.
-
In the desktop file browser, right-click test.ods and choose Open With->your favourite plaintext editor.
Expected result: text editor either shows gibberish or refuses to open the file on the grounds that it contains binary data, as is the normal behaviour when trying to open an ODS file with a text editor.
Actual result: text editor opens the file and reveals it to contain XML-formatted text data.
On reflection, this is almost certainly the workflow I used to create my own broken spreadsheet, so I no longer believe that the issue originally reported by @rgl is due to some mismatch of dropdown menu index meanings across LibreOffice versions.
Still annoying, though. I would have expected Calc to be smart enough to choose the default save format for an initially zero-length file from its filename extension rather than using a format that would normally require a different extension.
Can you check on the created test.ods BEFORE opening in Calc? Size? What do you see, when you open this in your text-editor?
.
If this new test.ods is actually flat xml Calc will not Change this, when you edit and save… But then the trap was laid before Calc was activated…
Quite easily reproducible:
touch empty.ods
soffice empty.ods
edit, save, it’s a Flat ODF file. Understandably, because opening the empty file it lacks the zip container and mimetype and META-INF/manifest.xml streams, so it can not be an ODF container file and must be saved as Flat ODF. Note that file name extensions are not an indicator of actual content, they are just some convention. (apart from that Windows does odd things based on file name extensions and applications try to mimic that broken behaviour).
It’s an empty (i.e. zero length) file. Empty files have no internal structure at all, so not only is it not an ODF container file when opened, it’s not a text file either. The only useful information Calc can possibly glean from the file at open time is its pathname.
.
Since there exists no existing format to preserve, Calc is completely free to choose one. Given that it already supports a convention that relates file formats to filename extensions, as demonstrated by the wording of the file format descriptions and the existence of the “automatic filename extension” option in the Save As dialog, I can see no good reason why it “must” ignore that convention under these circumstances. Nor can I see, in cases where it doesn’t even have a filename extension to use as a format hint, why it should avoid the long-established, long-standard ODS format in favour of an inefficient bloated flat XML format that only really exists for the benefit of a relatively tiny cohort of Git users.
.
Good software design conforms to the principle of least surprise, and having Calc’s default behaviour yield different results across platforms is surprising.
.
Despite the insistence of platform zealots on justifying every single piece of surprising software behaviour as a teachable moment, every method of storing file format metadata has both advantages and disadvantages. The Unix convention of relying on magic identifiers near the start of the file fails for zero-length files. The Windows convention of relying on filename extensions fails when files get imported from other platforms. The Mac convention of relying on multiple forks per file fails on filesystems that don’t support those. There is no objective standard by which any of these can reasonably be described as “broken behaviour”.
New empty files as created by every Linux desktop file browser I’m aware of are genuinely empty, i.e. zero length, i.e. have no content whatsoever. This is not the same behaviour as in Windows, where using the Windows file browser to create a new empty file actually makes Windows invoke an application hook whose job is to do the equivalent of launching the app with no file, then doing Save As with the pathname set to that of the file being created and all other options set to defaults.
.
Most Linux desktop apps that allow files to be edited in some way have a Save As option that allows the file format to be chosen automatically based on the filename extension. I was actually quite surprised to find that the closest that any of the Star Office descendants have to this is an option that works the other way around, i.e. lets you automatically append/force a filename extension based on the format you chose.
.
In any case, I can see no harm and much good in having the application treat the filename extension of any zero-length file that it’s asked to edit as a hint for the file format it’s supposed to Save in, or using a sensible default format if no such hint is available. And no, I would not rate Flat XML ODS as a sensible default format even if it didn’t trigger the chart data source bug. It’s nice to have it for interop with source code control systems but for general use? Thanks, no thanks.