Bug Hunting Session
Bug 63642 - Math formula looses custom font settings on save as Flat XML
Summary: Math formula looses custom font settings on save as Flat XML
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering ODF-Flat
  Show dependency treegraph
 
Reported: 2013-04-17 12:13 UTC by Mike Kaganski
Modified: 2019-05-22 14:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Formula->fodt test (238.47 KB, application/zip)
2014-12-03 06:49 UTC, Mike Kaganski
Details
Some ideas for file format if using settings (see A) (18.63 KB, application/vnd.oasis.opendocument.text)
2018-03-26 23:31 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2013-04-17 12:13:54 UTC
If a formula has some customized font settings, then these settings are lost upon saving the document as Flat XML. This happens both in documents (.fodt) and in spreadsheets (.fods)

Steps to reproduce.
1. Create a new empty document.
2. Insert->Object->Formula...
3. Type "a"
4. Format->Fonts... See that Variables are set to Times New Roman, Italic
5. Modify->Variables
6. Select Arial -> Ok -> Ok
7. See that the font of the formula is changed.
8. Save as a .odt, close and reopen to check that the settings persist (enter the formula and check the settings).
9. Save as a .fodt, close and reopen.

Expected results:
The font modifications should stay.

Actual results:
Initially the formula is shown correctly, but when opening it for editing, the font changes to Times New Roman and the settings in Fonts dialog are back to defaults. The initial correct display is possibly due to cached metafile of the formula.
Comment 1 Joel Madero 2013-04-18 02:21:33 UTC
Thank you for reporting this issue! I have been able to confirm the issue on:
Version 3.6.5.2 
Platform: Bodhi Linux 2.2 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well.

Marking as:

New (confirmed)
Minor - easy enough to change the font back, the format isn't standard so not affecting a lot of users, not preventing high quality work, on initial inspection it's fine, only if you need to edit the formula again

Low - default seems accurate in this case



+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 2 Mike Kaganski 2014-11-30 03:28:58 UTC
Tested with Version: 4.3.4.1
Build ID: bc356b2f991740509f321d70e4512a6a54c5f243

and also with Version: 4.4.0.0.beta1
Build ID: 9af3d21234aa89dac653c0bd76648188cdeb683e
Locale: ru_RU

The bug still persist, but the cached correct initial view is no more kept.
So, the problem is worse now.

The Flat XML ODT format is a standard format, that is, although not very common, still very useful in case when recoverying a corrupted file.

Now, if a file contain many formulas, they all become distorted at document opening (and even corrupted, if default font doesn't include some symbol that was used). This will make using that file very difficult.

I raise the importance to medium/normal. Hope that this is appropriate given the new behaviour.
Comment 3 Joel Madero 2014-12-02 23:19:00 UTC
Can you give an example file showing the corruption that you mentioned? If we can get confirmation that there is actual corruption then we can bump it one higher to major - high, but i prefer not doing this until we actually have an independent QA person saying they've seen corruption.

Thanks
Comment 4 Joel Madero 2014-12-02 23:20:03 UTC
I actually would rather it be at Major -> Medium as flat XML is not a common format at all (therefore this is unlikely to affect a lot of people). Additional proof is that nearly 2 years have passed and we have no one else commenting on the bug and no duplicates.
Comment 5 Mike Kaganski 2014-12-03 06:49:54 UTC
Created attachment 110393 [details]
Formula->fodt test

This attachment contain a TTF font and two text documents, which contents is just one formula object. Also, screenshots are included.

The font is used in our organization as stangard for engeneering drawings, calculations and documents. Its use is mandatory to guarantee consistent look of our documentation. It contain some non-standard character in private area, that correspond to Russian GOST symbols.

The formula in document simply contain those characters. In original (ODT) document, if the font is awailable in the system, the characters are OK. It is apparent on formula-odt.png. When exported to FODT, on reopening the formula becomes "corrupted" (see formula-fodt.png).

Please note that no data loss in formula happened; if the font is restored manually, it will be OK again. But (1) the process may be very time-consuming with big documents with many formulas, and (2) there may be situations when either correct font is unknown, or a formula is overlooked. Thus, the result may be wrong. So, missing font information still may qualify as data loss...
Comment 6 QA Administrators 2015-12-20 16:10:21 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2015-12-20 22:28:31 UTC
Still reproducible with Version: 5.0.4.2 (x64)
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: ru-RU (ru_RU)
Comment 8 QA Administrators 2017-01-03 19:57:24 UTC Comment hidden (obsolete)
Comment 9 Mike Kaganski 2017-01-04 20:33:34 UTC
Still reproducible with Version: 5.3.0.1 (x64)
Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (ru_RU); Calc: group
Comment 10 m.a.riosv 2017-02-14 09:14:02 UTC
Perhaps we should raise the importance to critical, it's on an ODF format.
Comment 11 Jouni Järvinen 2017-02-14 19:56:48 UTC
(In reply to Mike Kaganski from comment #0)
> If a formula has some customized font settings, then these settings are lost
> upon saving the document as Flat XML. This happens both in documents (.fodt)
> and in spreadsheets (.fods)
> 
> Steps to reproduce.
> 1. Create a new empty document.
> 2. Insert->Object->Formula...
> 3. Type "a"
> 4. Format->Fonts... See that Variables are set to Times New Roman, Italic
> 5. Modify->Variables
> 6. Select Arial -> Ok -> Ok
> 7. See that the font of the formula is changed.
> 8. Save as a .odt, close and reopen to check that the settings persist
> (enter the formula and check the settings).
> 9. Save as a .fodt, close and reopen.
> 
> Expected results:
> The font modifications should stay.
> 
> Actual results:
> Initially the formula is shown correctly, but when opening it for editing,
> the font changes to Times New Roman and the settings in Fonts dialog are
> back to defaults. The initial correct display is possibly due to cached
> metafile of the formula.

After performing a clean reinstall from 5.2.2.2 x64 to 5.3.0.3 x64, the results have changed:
1) The repro steps are better now: the ODT where the small A was written preserved the font as italic Arial, but the FODT uses the default italic Liberation Serif and Liberation Mono.
2) In the attachment: the ODT preserved all the font changes and looks just like the pic. The FODT switched back to the defaults of Liberation Serif, Liberation Mono and the italics, and is the exact same mess as in the pic. When double-clicking the formula in the ODT, it presents the same kinda mess in the formula box on the bottom of screen as you see immediately in the FODT. The box does track each character successfully in that wherever you move the keyboard cursor it highlights the corresponding symbol on the document in both FODT and ODT.
Comment 12 Mike Kaganski 2017-02-14 20:46:18 UTC
Unfortunately no.

1. The repro steps aren't any better, exactly as you described it. The ODT has always kept the font information, as it is now (see my repro step 8 in comment 0 - "check that the settings persist"). And FODT still looses the data.

2. The attachment contains, among other files, the required font, without which the display both in FODT *and* in ODT will be wrong. That is explained in comment 5.
Comment 13 QA Administrators 2018-03-24 03:31:48 UTC Comment hidden (obsolete)
Comment 14 Mike Kaganski 2018-03-26 07:47:12 UTC
Still reproducible with Version: 6.0.3.1 (x64)
Build ID: 62abb169b0efa1520d7bee1f586865354060b989
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL

Regina: could you please advise on this? I don't see a "flat" filetype for the Math documents; so I cannot understand how should be the export implemented properly...
Comment 15 Regina Henschel 2018-03-26 11:20:52 UTC
Each Math-object is a separate document in the packed file format. As such it has its own settings.xml. Currently this settings.xml parts are dropped totally in flat format. The flat format has only one <office:settings> element, and this contains the settings for the surrounding document and none of the settings for the Math-objects.

There are several solutions possible:
A Extend the <office:settings> element
B Convert the Math-objects settings into CSS styles and put them into the <math> element
C Change the way a Math.object is embedded from the nesting <draw:object><math> to <draw:object><office:document>...<math> for flat file format

I personal would prefer B, because that is the only way to write MathML in a way, that allow other applications to show the formulas as intended by the author. It should be preferred in the long run. But because we currently still rely on "StarMath 5.0", and input of pure MathML still needs a lot of improvement, this might give a bad user experience in the short run.

Currently only LibreOffice itself writes flat format, so version A and C are both possible. Because all three ways mean a large change in document structure, I suggest to discuss it on the dev-mailing list, so that the audience is wider.
Comment 16 Regina Henschel 2018-03-26 11:52:02 UTC
Looked once again: C would not help. But further option would be to put the settings into the <office:object> element in a loext: namespace.
Comment 17 Mike Kaganski 2018-03-26 12:59:39 UTC
(In reply to Regina Henschel from comment #16)
> Looked once again: C would not help.

Sorry: I don't see why? C is the way Spreadsheet embedding into text document works; there are <office:meta>; <office:settings>; <office:scripts>; ... etc, and finally, <office:body> with the spreadsheet itself, all inside <office:document>. Why can't it be reused for Math - and be better for consistency?
Comment 18 Regina Henschel 2018-03-26 14:04:31 UTC
(In reply to Mike Kaganski from comment #17)
> (In reply to Regina Henschel from comment #16)
> > Looked once again: C would not help.
> 
> Sorry: I don't see why? C is the way Spreadsheet embedding into text
> document works; there are <office:meta>; <office:settings>;
> <office:scripts>; ... etc, and finally, <office:body> with the spreadsheet
> itself, all inside <office:document>. Why can't it be reused for Math - and
> be better for consistency?

In case of a spreadsheet you have the nesting <office:document> <office:body> <office:spreadsheet>. But <office:body> has nothing similar for Math, there exists not <office:math>. You need a <draw:object> as parent of a <math:math> element and a <draw:frame> as parent of the <draw:object>. But a <draw:frame> element needs a parent too, which would be a <office:text>, a <draw:page> or a <table:shapes> e.g. All together this means, that you embed a document, which in turn has a math-object embedded. So it is the same problem as now, only one level down.

If you would really write such structure, you would not be able to distinguish it from e.g. a Draw-document embedded in a Writer-document where the Draw-document contains a Math-formula.

I too was allured by then having an additional <office:settings> element.
Comment 19 Regina Henschel 2018-03-26 23:31:25 UTC
Created attachment 140896 [details]
Some ideas for file format if using settings (see A)
Comment 20 QA Administrators 2019-05-22 02:53:19 UTC Comment hidden (obsolete)
Comment 21 Regina Henschel 2019-05-22 14:19:33 UTC
I see the problem still in Version: 6.3.0.0.alpha0+ (x64)
Build ID: ccf3a0600ee902390ad6112ecf28223078bdd2db
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-13_03:08:59
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded