Description: I launch lomath Then I type a %Ux003C b newline in the text editor (%Ux003C is the "less than" caracter) StarMath then displays the graphic equation a%Ux003Cb (%Ux003C is not interpreted.) Then, I launch lowriter. In this writer window, I load a document docA containing equations that use Ux003C to display the "less than" char. Everything is right in this document, "Ux003C" appears as "<". Note that this Ux003C symbol does not occur on the first page of the document. Going back to the equation editor, I re-run the starmath parser (by adding a char, removing the char). Equation stays the same. %Ux003C is still not interpreted. But then, I scroll to the equation that use the %Ux003C as starmath code, scrolling until this equation is onscreen. Finally, going back to the equation editor, I add and remove a char again. And this time, %Ux003C is interpreted by starmath and graphical part shows "a < b". Note that if I save this equation, the document now acts as docA as soon as equation is displayed. That's weird. Steps to Reproduce: write an equation like a %Ux003C b Actual Results: %Ux003C is sometime interpreted, sometime not, depending on other opened documents. Expected Results: I don't even know if %Ux003C should be interpreted, but I rely on some documents using it. Reproducible: Always User Profile Reset: No Additional Info: Build info : Version: 5.2.7.2 Build ID: 1:5.2.7-1+deb9u4 Locale : fr-FR (fr_FR.utf8);
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
its possible that the import code is adding symbols to the symbol set, and names the symbol %Uwhatever and uses the unicode point of the symbol as the whatever. Attach the example where it does work for comparison.
Created attachment 147670 [details] This document contains the %Ux003C equation This document provides a working example ./Object 1/content.xml : <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"> <semantics> <mi mathvariant="normal"><</mi> <annotation encoding="StarMath 5.0">%Ux003C</annotation> </semantics> </math> (newline in content.xml added by me)
./Object 1/settings.xml has <config:config-item-map-indexed config:name="UserDefinedSymbolsInUse"> <config:config-item-map-entry> <config:config-item config:name="Name" config:type="string"> Ux003C </config:config-item> So you are right that symbol is defined by the document. Still, the editing of a document should not be affected by other opened documents!
The regular way to use an own symbol is to add it to a symbol set. This information is stored into the registrymodifications.xcu file in the user profile. To make sure the symbol is available to other readers of the document, the symbol is stored into the settings.xml in the math-object in the document. But symbol sets are only relevant for StarMath. From point of ODF, StarMath does no exist. MS Word would not be able to use this information for example. If you use the %-notation without having the symbol included into a symbol set, how should LibreOffice know, which symbol it is? While LibreOffice is running, it holds the symbol sets of the formulas it has already shown. That makes it possible to use a symbol, which is defined in an already existing formula but not in your user profile. That is a useful feature, because users can easily use symbols defined by other authors and can edit the formulas in foreign documents. I think, that there is no bug in the current behavior. Only the symbol set UI is confusing, that it does not distinguish between the different origins of the available symbols.
> While LibreOffice is running, it holds the symbol sets of the formulas it has already shown. That makes it possible to use a symbol, which is defined in an already existing formula but not in your user profile. That is a useful feature, because users can easily use symbols defined by other authors and can edit the formulas in foreign documents. The feature being useful is not related to relying on what formula have been *shown*, which seems misleading (at least to me). I think it would be more correct to import the symbol in the other document on explicit user action (copy/paste formula).
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear vivien.guillet, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear vivien.guillet, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp