Bug 76900 - FILESAVE: Flat XML format broken. Formula size not preserved in roundtrip.
Summary: FILESAVE: Flat XML format broken. Formula size not preserved in roundtrip.
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: ODF-Flat
  Show dependency treegraph
 
Reported: 2014-04-01 11:56 UTC by Callegar
Modified: 2023-10-18 06:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document (14.35 KB, application/vnd.oasis.opendocument.presentation)
2019-05-22 09:16 UTC, Callegar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2014-04-01 11:56:05 UTC
Problem description:

When saving a drawing including formulas using the standard odg and odp formats, everything is fine. Using the fodg and fodp formulas, the roundtrip is broken.  Formula objects are read back with incorrect object size.

Steps to reproduce:
1. Create drawing
2. Add a formula to the drawing
3. Save as fodg
4. Load back the drawing
5. The formula has an incorrect size
6. Formula size can be recovered by right clicking and restoring to original size.
Operating System: All
Version: 4.2.3.1 rc
Comment 1 Buovjaga 2014-10-29 12:14:24 UTC
I reproduce -> NEW.

More detailed instructions for n00bs like me: Insert - Object - Formula

Win 7 64-bit Version: 4.4.0.0.alpha1+
Build ID: 4586a3f564600f1a0ce15a5cb98868b43bb9351e
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-29_07:28:16
Comment 2 Buovjaga 2015-01-07 15:54:30 UTC
Lowered version number after reproducing with:

Ubuntu 14.10 64-bit
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

Priority, too: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 3 Callegar 2015-01-08 08:27:25 UTC
Based on the Prioritizing_Bugs_Flowchart shouldn't it be a blocker?

- Does the bug cause [] loss of data, [] broken core functions (inability to save) [] ?

Yes -> It causes loss of data when saving to a native file format (flat odf).

- Does this bug happen very frequently on clean install/install attempt?

Yes -> It happens always, when trying to save to a native file format (flat odf).
Comment 4 Buovjaga 2015-01-08 08:37:23 UTC
(In reply to sergio.callegari from comment #3)
> Based on the Prioritizing_Bugs_Flowchart shouldn't it be a blocker?
> 
> - Does the bug cause [] loss of data, [] broken core functions (inability to
> save) [] ?
> 
> Yes -> It causes loss of data when saving to a native file format (flat odf).

It doesn't cause loss of data, though. Size is a cosmetic change.
Comment 5 Callegar 2015-01-08 09:14:18 UTC
Sorry, I did not know that in a presentation or a drawing, the appearance that takes a lot of time to carefully craft was not data. Wonder why people use presentations and drawings at all when they could use real data.
Now, seriously.  In a drawing, the relative position and size of objects is first class information. Reading that in a drawing relative size is not data is sort of painful.

May I suggest that until flat odf support can be fixed, saving as flat odf triggers the opening of the a window saying that

"This document may contain formatting that may fail to save in the currently selected file format "flat odf". Use the default ODF file format to be sure that the document is saved correctly"

as for the non native formats? This could save hours of work.
Comment 6 Joel Madero 2015-01-09 16:59:46 UTC
Well this definitely is not a blocker. In 3+ years I've seen exactly 2 blockers and those were really in fact quite terrible bugs that would affect the vast majority of users on certain platforms. 

Talking to beluga now on chat to see if there is a workaround - if there is, it's minor, if there isn't, it is a normal bug (prevents high quality work).

Core functionality is something like "ability to print" or "ability to type" - not what this bug is referencing.
Comment 7 Buovjaga 2015-01-09 17:02:23 UTC
Well ok let's put it back to normal severity. There is no way to restore multiple formulas to original size.
Comment 8 Callegar 2015-01-10 08:28:11 UTC
I agree with your analysis. Possibly, the steps to get to 'blocker' on the flowchart are a bit too easy to take, since the second step seems to be based just on 'reproducibility' and not on 'impact' (namely, the share of people who actually cannot do without the feature). 

Coming back to this bug, I think that 'normal' is OK. Unfortunately, things marked as 'minor' tend to be overlooked, not just by developers but also by users themselves when they resort to the bug database to see if something that they are observing is a known broken behavior.
Comment 9 Callegar 2016-01-04 09:34:24 UTC
Bug is still present as of 5.1.0.1 and with it, LibO flat xml remains of no practical use, unless one:

- is sure that the docs contain no math; or
- uses the texmath extension for math
Comment 10 Callegar 2016-01-06 19:29:24 UTC
Just noticed that the bug is not restricted to formulas. It affects all embedded objects. For instance, if you embed a spreadsheet into a drawing and save as flat xml, then the spreadsheet size is lost on reload.
Comment 11 Callegar 2016-02-16 14:50:35 UTC
Still present in 5.1.1 RC 1.

Please, at least have flat opendocument XML provide a dialog similar to that for non native formats warning for possible formatting losses when using this format.

Having the expectation that flat XML is lossless when in fact it is not causes a huge waste of time when documents need to be re-edited to fix the roundtrip artifacts or big embarrassment when projecting broken slides.
Comment 12 QA Administrators 2017-03-06 15:07:50 UTC Comment hidden (obsolete)
Comment 13 Callegar 2017-03-07 12:35:36 UTC
Bug still present as of 5.3.1 RC 1.

Would tend to say that flat xml formats do more harm than good. Sorry for insisting, but warning should exist against using them until they can provide correct roundtrips, because:

1) people tend to interpret them as "native" and such as guaranteeing no data loss
2) Many think that they are a good format for having LibO interact with git (since deltas can be properly obtained for them).
Comment 14 Regina Henschel 2018-01-09 13:02:04 UTC
The reason is, that LibreOffice stores a lot of things into file settings.xml. In case of a draw:object, e.g. Math or Spreadsheet, this object is in a sub-folder "Object" and therein has its own file settings.xml. If the document is transformed to one file when saving to flat format, the settings of the objects are thrown away currently.

In ODF the settings are in an element <office:settings> with child elements <config:config-item-set>, which are distinguished by an attribute config:name. So a short-term solution can be, to add the settings of the objects and construct the config:name value in a way, that the relationship to the object can be reconstructed.

The element <office:settings> is specified in 3.10.1 with the description
<quote>
The <office:settings> element contains one or more <config:config-item-set> elements, each of which represents a set of application settings.
</quote>
Other application may ignore <office:settings> totally. Therefore information which are relevant for the document itself, must not be stored in this element. LibreOffice ignores this in many places.

In case of Math objects, all information which are essential for rendering the formula have to be inside the <math:math> element itself. But there are so much MathML features missing in LibreOffice, that it is a long-term task.

I support the idea of enabling a warning, when saving in flat format. In addition the help text should list, which information is actually lost.
Comment 15 QA Administrators 2019-05-22 02:52:02 UTC Comment hidden (obsolete)
Comment 16 Callegar 2019-05-22 09:16:35 UTC
Created attachment 151589 [details]
Sample document
Comment 17 Callegar 2019-05-22 09:33:17 UTC
Bug is still present as of 6.2.4.2.

Sample test case attached.

To reproduce:

1) open the document
2) save as fodf
3) Reload

Most seriously, LibO still does not even warn about data loss when saving in flat formats. This is a very big issue, because the flat formats appear to users as mere "flat" variations of *native* formats, so the occasional user thinking he/she can take advantage of these formats will not expect data loss with them and get badly burned.

Being that flat formats have been broken since 3.5 (now seven years ago) I think that it is safe to assume that there not a huge adoption for them. May I suggest that saving (saving only) in these formats is disabled (with possible reactivation under the "experimental features" toggle)?
Comment 18 Regina Henschel 2019-05-22 14:40:36 UTC
Workaround: Do not use the settings for the font size but write the font size directly into the formula. That is the way font size is handled by the extension DMath.
Comment 19 Emanuele Gissi 2021-04-16 10:20:24 UTC
(As in the linked bug, I am adding a comment and an example case.)

Yes, I agree the flat formats should never have loss of formatting!
This format is infact very useful for git versioning:
https://wiki.documentfoundation.org/Libreoffice_and_subversion
and formulas are important for tech doc.

As an example case, here is the Italian Fire Safety Code on Github:
https://github.com/codicepi/codicepi-edit
Comment 20 phv 2021-10-17 11:40:56 UTC
I just wasted an hour trying to figure out why the fonts defined for my formulas were lost after each save. Please at least give a warning when saving.

For a basic user like me, it seems obvious that a format called fodt should keep all the data, because of its similarity with the odt format.
Comment 21 Callegar 2021-10-17 14:22:53 UTC
The flat XML file format has been broken or at least half baked virtually forever and no one really cares about them.

Even the legitimate user case of improving the ability to store opendocument formats in git repos has been addressed by "rezip" scripts (see https://github.com/costerwi/rezip if this was the reason for being interested in flat XML). They are certainly slow and sub-optimal but good enough for practical usage cases.

My two cents: ability to write in flat XML should be disabled and the ability to enable it should be hidden behind the experimental features because it is just a source of frustration and data loss. Ability to read should be left in case someone has flat XML opendocument files around (because alone it is harmless).
Comment 22 QA Administrators 2023-10-18 03:14:56 UTC Comment hidden (obsolete)
Comment 23 Emanuele Gissi 2023-10-18 06:37:27 UTC
The bug is still present in:

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: it-IT (it_IT.UTF-8); UI: it-IT
Flatpak
Calc: threaded