Download it now!
Bug 133647 - The docx equation does not convert properly in newest LO
Summary: The docx equation does not convert properly in newest LO
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.7.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.2
Keywords:
Depends on:
Blocks: DOCX-Fields Regressions-expression-is-faulty 118682
  Show dependency treegraph
 
Reported: 2020-06-03 19:26 UTC by Rhys Young
Modified: 2020-11-20 13:52 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
The test file (21.20 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-03 19:27 UTC, Rhys Young
Details
Updated file where more issues can be seen (29.06 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-20 13:52 UTC, Rhys Young
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rhys Young 2020-06-03 19:26:43 UTC
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
Comment 1 Rhys Young 2020-06-03 19:27:04 UTC
Created attachment 161593 [details]
The test file
Comment 2 Michael Warner 2020-06-06 13:17:57 UTC
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.
Comment 3 Michael Warner 2020-06-06 13:58:11 UTC
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.
Comment 4 Michael Warner 2020-06-06 14:27:24 UTC
> 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
Comment 5 Michael Warner 2020-06-06 14:33:30 UTC
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.
Comment 6 Michael Warner 2020-06-06 18:38:13 UTC
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".
Comment 7 Michael Warner 2020-06-06 19:40:31 UTC
A table formula of "sum(1,2,3)" or "min(1,2,3)" also prints the "Expression is faulty" message.
Comment 8 Regina Henschel 2020-06-07 11:55:56 UTC
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>
Comment 9 Michael Warner 2020-06-09 12:55:13 UTC
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.
Comment 10 Michael Warner 2020-06-29 01:13:11 UTC
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.
Comment 11 Michael Warner 2020-08-02 13:24:05 UTC
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
Comment 12 Commit Notification 2020-08-17 09:16:11 UTC
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.
Comment 13 Commit Notification 2020-08-17 21:30:59 UTC
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.
Comment 14 Commit Notification 2020-08-31 17:33:00 UTC
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.
Comment 15 Commit Notification 2020-09-02 13:51:35 UTC
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.
Comment 16 NISZ LibreOffice Team 2020-09-08 10:57:08 UTC
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
Comment 17 Rhys Young 2020-11-19 14:25:50 UTC
Tested in latest LO daily release and still seems to be a problem 7.0.4
Comment 18 Buovjaga 2020-11-19 16:02:41 UTC
(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.
Comment 19 Buovjaga 2020-11-19 18:19:21 UTC
(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
Comment 20 Buovjaga 2020-11-20 09:58:15 UTC
(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.
Comment 21 Rhys Young 2020-11-20 13:50:20 UTC
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
Comment 22 Rhys Young 2020-11-20 13:52:20 UTC
Created attachment 167419 [details]
Updated file where more issues can be seen