Description: When opening the file in LO 7 it does not yield the right result and gives a **Expression is faulty ** error. Steps to Reproduce: 1.Open file in LO 7 2.Compare file to word Actual Results: Yields expression is faulty error. Expected Results: Should yield proper result Reproducible: Always User Profile Reset: No Additional Info: N/A
Created attachment 161593 [details] The test file
In Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.2, I get **Expression is faulty** in both Row two and Row total. In Version 7.1.0.0.alpha0+, I get 429.55 (the correct answer) in Row two, but **Expression is faulty** in Row total.
When I look at the formula fields in LibreOffice 6, I see this: 250*0.75*4/11*6.3 \# "0" \* MERGEFORMAT and SUM(D2:D5) \# "0" \* MERGEFORMAT In the docx file, the formulas are stored like this <w:instrText xml:space="preserve"> =250*0.75*4/11*6.3 \# "0" \* MERGEFORMAT</w:instrText> and <w:instrText xml:space="preserve"> =SUM(D2:D5) \# "0" \* MERGEFORMAT</w:instrText> The '=' signs are missing in the formula field, but I don't know if that is expected. I also don't know if ' \# "0" \* MERGEFORMAT' is expected to be valid syntax here.
> I also don't know if ' \# "0" \* MERGEFORMAT' is expected to be > valid syntax here. Looks like it is: http://www.officeopenxml.com/WPfieldInstructions.php
When I look at the Formula fields in LibreOffice 7, the formatting switches aren't shown. So the display of them must have been fixed since LO 6.
It somehow computes the values correctly (although they aren't formatted yet, the result is shown to 12 decimal places). Then DocumentFieldsManager::UpdateTableFields() runs, which calls SwTableFields::CalcField(), which calls SwCalc::Calculate(), which which is parsing the expression into nodes for formatting (I think). This is successful up to SUM(, but it sets a SwCalcError::FaultyBrackets in calc.cxx:1156 when m_eCurrOper doesn't equal a CALC_RP. Looks like something is going wrong when it looks at "D2:D5".
A table formula of "sum(1,2,3)" or "min(1,2,3)" also prints the "Expression is faulty" message.
The formula syntax for a Writer table is different from Calc. The sum function has no function brackets at all. The sum function operates on a list. A cell reference is written with < >. Example: The Calc formula =sum(A1*A2;B1*B2) has to be written in Writer as =sum <A1>*<A2>|<B1>*<B2> Only the colon for a range is the same. The Calc formula =sum(A1:B2) has to be written in Writer as =sum <A1:B2>
Mike Kaganski suggested the issue may be that the import/export filter isn't converting the formulas. I'll spend some more time looking at it this weekend.
Just as an update, I am still working on this. I've run into some trouble with trying to create the unit test, and sent a question out to the mailing list. Meanwhile, I am moving forward with writing a proposed solution.
I submitted a patch for this a while ago. It's just waiting for someone to review it. https://gerrit.libreoffice.org/c/core/+/98614
Michael Warner committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/68e74bdf63e992666016c790e8e4cfd5b28d6abe tdf133647 tdf123386 tdf123389 Improved .docx table formula import It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/82189fdc93ac337e1de3379d678eca6b7654e6fc tdf133647 tdf123386 tdf123389 fix DOCX table formula export It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Warner committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/a8dbdf4c41d0299aee6e155323f217e2fa1565c9 tdf133647 tdf123386 tdf123389 Improved .docx table formula import It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/8f1cb34bdb523e17478de2b0ef7d745c29743df7 tdf133647 tdf123386 tdf123389 fix DOCX table formula export It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in: Version: 7.1.0.0.alpha0+ (x64) Build ID: a3b4831208da615789bd1e2d5660dd130807f504 CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: en-GB (hu_HU); UI: hu-HU Calc: threaded
Tested in latest LO daily release and still seems to be a problem 7.0.4
(In reply to Rhys Young from comment #17) > Tested in latest LO daily release and still seems to be a problem 7.0.4 You still get "**Expression is faulty **"? Because I get no such thing with Arch Linux 64-bit Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.0.3-2 Calc: threaded Row total is different upon opening in 7.1, though. In 7.0 it is 549.55. In 7.1 it is 877.00..., but after focusing in the cell, it changes to 549.55. The decimal precision of Row two and Row total is also much higher before focusing on either cell. I guess the change should be bibisected.
(In reply to Buovjaga from comment #18) > Row total is different upon opening in 7.1, though. In 7.0 it is 549.55. In > 7.1 it is 877.00..., but after focusing in the cell, it changes to 549.55. > The decimal precision of Row two and Row total is also much higher before > focusing on either cell. I guess the change should be bibisected. Reported as bug 138348
(In reply to Buovjaga from comment #19) > (In reply to Buovjaga from comment #18) > > Row total is different upon opening in 7.1, though. In 7.0 it is 549.55. In > > 7.1 it is 877.00..., but after focusing in the cell, it changes to 549.55. > > The decimal precision of Row two and Row total is also much higher before > > focusing on either cell. I guess the change should be bibisected. > > Reported as bug 138348 This wasn't even a bug after all. But now, Rhys, you really need to be more specific about what problem you are seeing in 7.0.4.
Hello, Sorry I have a larger file with more cases to test with, this file includes many cases where I am getting the **Expression is faulty** originally it was not submitted since I was told not to submit large files. Attaching the file regardless for validation. Visible in latest LO :) Thanks, Rhys
Created attachment 167419 [details] Updated file where more issues can be seen
(In reply to Rhys Young from comment #22) > Created attachment 167419 [details] > Updated file where more issues can be seen This file was saved by LibreOffice. app.xml inside has: <Application>LibreOfficeDev/7.0.4.0.0$Windows_X86_64 LibreOffice_project/acddc14fef3f3d34c9f2218545364ff37815b507</Application> :) Please submit a docx file that does work in Word but not in Writer - and please open a new bug for such cases.