Created attachment 200248 [details] A simple reproducer In the attachment, there is a table with "1", "2" and "3" in A1, A2, and A3; A4 has a formula =sum<A1:A3> Saving the document to DOCX and reloading produces ** Expression is faulty ** in A4. Opening in Word, and updating the field in A4, produces "!Syntax error, :". Started in 7.1; in 7.0, the formula was exported as simple value.
Could reproduce Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
if the formula is changed from '=sum<A1:A3>' to '=sum(<A1:A3>)' before saving then it works
The issue started to happen after commit cf596c43315bb96b5e7256a82256f1ccb8c9c4d0 [log] author László Németh <nemeth@numbertext.org> Thu Aug 13 12:05:20 2020 +0200 committer László Németh <nemeth@numbertext.org> Fri Aug 14 09:13:03 2020 +0200 tree aa81fa39cefaeb670db98fc5278ea0bdadecc9d3 parent 6457d46967f8dbb41199b750d59edde839f24b5d [diff] tdf#133163 DOCX: export formula cells
Regarding formula syntax, see https://bugs.documentfoundation.org/show_bug.cgi?id=133647#c8
My take on it: https://gerrit.libreoffice.org/c/core/+/183967
after a second thought, this is an import issue, and not a export issue. it has to be fixed in convertFieldFormula in sw/source/writerfilter/dmapper/DomainMapper_Impl.cxx
(In reply to Xisco Faulí from comment #6) I'm sorry, how can a formula exported as "=sumA1:A3" be *imported* with correction? The token "sumA1" is a valid name, and is *not* the same as "sum(A1" or "sum A1".
(In reply to Mike Kaganski from comment #7) > (In reply to Xisco Faulí from comment #6) > > I'm sorry, how can a formula exported as "=sumA1:A3" be *imported* with > correction? The token "sumA1" is a valid name, and is *not* the same as > "sum(A1" or "sum A1". Hi Mike, Can you give an example where "sumA1" could be a valid name ?
(In reply to Xisco Faulí from comment #8) You may create arbitrary variables in Writer, using "Define variable" field [1], and there you define the names (e.g., sumA1); and then you may use these names in formulas, including table formulas. In Word, there is no fields like that, but there is a programmatic way to define document variables [2]. However, I don't know if these variables may be used like that in "formula" fields. But even if the above didn't exist: * Word can't read that formula correctly, so it *is* exported incorrectly; * We can't assume that tomorrow, there won't appear a new function with a name that clashes with something that we decide to parse like what you suggest. And really, that "this is an import issue, and not a export issue" was shocking for me :) [1] https://help.libreoffice.org/25.2/en-US/text/swriter/01/04090005.html [2] https://support.microsoft.com/en-us/topic/how-to-store-and-retrieve-variables-in-word-documents-3a912a35-42a0-7a28-7f2d-787ed6afb566
before I (In reply to Mike Kaganski from comment #9) > * Word can't read that formula correctly, so it *is* exported incorrectly; I think this is not correct. if you revert a586ce188086ff27b08b8a4de4672c07ddf8ed7c causing bug 166125, then Word is able to read the formula correctly and 6 is displayed ( at least with Office 2016 ) that's why I assumed it was a import issue and not an export issue. Replacing < and > with spaces would cause many tests to fail ( https://ci.libreoffice.org/job/gerrit_linux_gcc_release/186458/consoleFull#1682007923d893063f-7f3d-4b7e-b56f-4e0f225817cd ) so we either adapt those tests as well or we also have to add a regexmatcher to convertFieldFormula to remove the spaces
(In reply to Xisco Faulí from comment #10) > (In reply to Mike Kaganski from comment #9) > > * Word can't read that formula correctly, so it *is* exported incorrectly; > > I think this is not correct. if you revert > a586ce188086ff27b08b8a4de4672c07ddf8ed7c causing bug 166125, then Word is > able to read the formula correctly and 6 is displayed ( at least with Office > 2016 ) ... until you refresh the field - which means, it only shows a cached value, and that is unrelated to the correctness of formula handling :-)
(In reply to Mike Kaganski from comment #11) > (In reply to Xisco Faulí from comment #10) > > (In reply to Mike Kaganski from comment #9) > > > * Word can't read that formula correctly, so it *is* exported incorrectly; > > > > I think this is not correct. if you revert > > a586ce188086ff27b08b8a4de4672c07ddf8ed7c causing bug 166125, then Word is > > able to read the formula correctly and 6 is displayed ( at least with Office > > 2016 ) > > ... until you refresh the field - which means, it only shows a cached value, > and that is unrelated to the correctness of formula handling :-) indeed. I missed that step. Thanks!!
it seems using spaces also caused a Syntax error, so the way to go is by using parentheses
(In reply to Xisco Faulí from comment #13) > it seems using spaces also caused a Syntax error, so the way to go is by > using parentheses * causes a Syntax error in Word after updating the field
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7f8602e4feac16b5d0f6b80b93d5be6378f0aa11 tdf#166102: replace < and > with parentheses It will be available in 25.8.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/9bbd80c06ed0b563184882873fbe129b245504e5 tdf#166102: replace < and > with parentheses It will be available in 25.2.4. 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.