Description: The first problem is that fractions with comma-separated decimals not surrounded by {} are broken. The second problem is that extra space added between integer part of decimal and comma. Steps to Reproduce: 1. Open LibreOffice Math 2. Type "1,3 over 2 = 0,65" (without quotation marks) 3. See the preview window Actual Results: The formula rendered like ,3 1 ---- =0 ,65 2 See wrong.png attachment. Pay attention the position of 1 and the extra space between 0 and , Expected Results: The formula rendered like 1,3 ---=0,65 2 See right.png attachment (made with LO 5.3.7) Reproducible: Always User Profile Reset: No Additional Info: Formulas created in previous versions of the LO will be broken when editing in new versions. Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded Also confirmed with LO Version 6.2.5.2 on another computer with windows 7 x64.
Created attachment 153279 [details] formula preview, generated with LO 6.3.0
Created attachment 153280 [details] formula preview, generated with LO 5.3.7
Repro with Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
reproducible as described with LO 6.2.5.2, but not with LO 6.1.6 seems to work if entered with quotation marks: "1,3" over 2 = 0,65
Regression after https://git.libreoffice.org/core/+/9336286a7ea5385541344f444e6f8702c85bdacb
Hi Kribly Krably, I reproduce too with LO 6.4.0.0.alpha0+ (x86) Build ID: 5ba84c3c7080d55d86b8b39db077b6da36cb700a CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; Locale: fr-FR (fr_FR); UI-Language: en-US Calc: CL LO 6.2.0.0.alpha0+ Build ID: 1aa37aa6bee19099b57555a6d839992b054aa405 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-09-23_10:17:54 Locale: fr-FR (fr_FR); Calc: threaded but not with LO 6.2.0.0.alpha0+ Build ID: 7e65a0794b7c57210779bb9a6d1f2b2e49eb86e9 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-07-30_23:37:44 Locale: fr-FR (fr_FR); Calc: CL But it seems to me, as recommanded in https://wiki.documentfoundation.org/images/2/26/MG44-MathGuide.pdf, p. 24, you have to use braces to enclose this part of the formula. In this cas,I don't reproduce Jacques
(In reply to Jacques Guilleron from comment #6) Unfortunately, this is not a solution: 1. It puts extra effort on users whose locale uses comma for decimal separator; 2. It puts the need to edit formulas in existing documents once they are entered - and the discussed change might not be noticed at once, leaving formulas in broken state; 3. It keeps an *extra space* between the preceding number and the decimal comma.
(In reply to Jacques Guilleron from comment #6) > But it seems to me, as recommanded in > https://wiki.documentfoundation.org/images/2/26/MG44-MathGuide.pdf, p. 24, > you have to use braces to enclose this part of the formula. The mentioned part of the guide states literally this: > LibreOffice Math knows nothing about order of operation within a formula. You must use braces (curly brackets) to state the order of operations that occur within a formula. So that text clearly indicates that the braces are needed to *define the order of operation*. In this case, the problem is that Math *incorrectly* treats parts of one single floating-point number as different entities.
*** This bug has been marked as a duplicate of bug 127873 ***