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

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

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).

(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.

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.

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.

Well ok let's put it back to normal severity. There is no way to restore multiple formulas to original size.

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.

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

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.

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.

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).

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.

Created attachment 151589 [details]
Sample document

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)?

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.

(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

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.

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).

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