Library: The error occurs starting with “Aspose-Word for Java, version 17.5" up to the most recent version. I did two samples of older libraries: 17.4 and 13.9. Both these older libraries did not contain the error I am about to describe. I also downloaded the newest version (21.11 at the time of writing), which still consists of the bug. Therefore my conclusion is that the bug got introduced in 17.5 and was not an issue in the prior versions.
Summary: There seems to be an issue with the Aspose-method “Document.updateFields()” if those fields are within a table. It does not matter if the input number value is in a separate field (in the table) or just in the cell of the table. If I calculate the result of a cell that is formatted with dot as thousand separator in another field, the given result will be incorrect. The thousand separator seems to interpreted as decimal separator instead. Word itself handles this correctly on a manual refresh (select everything with CTRL + A and press F9).
More Details: In Germany, it is common practise to use a dot to separate thousand-values and a comma to separate decimal values (this is the default in many German systems as well, for example OS). Therefore, we unfortunately cannot “avoid” this notation.
I have a table that is filled with a row that consists of our input data and a second row that contains the calculated results as fields. This field is formatted with “number format #.##0” in all four lines. The calculation itself is simply multiplying a given number by two. I filled the table with four lines to show to different outcomes and thus presenting the erroneous calculation.
- In the first line, I formatted the input number value the German way with a dot as thousand-separator. The result is not what I expected: Instead of being doubled, the input number was only read until the dot and only that value in front of the dot was doubled.
- The second line is the same number value, but this time it is formatted without the dot. The calculated result here is obviously correct.
- In the third line, I inputted the number value using a comma (for decimals). The calculated result is correct.
- The fourth line is the value, this time provided with both a dot as thousand-separator as well as a comma to separate decimals. Again, the calculated result is correct.
Conclusion: When the input number value only contains a dot (but no additional comma), the field containing the calculated result is incorrect (the calculation only takes the part in front of the dot into account).
Steps to reproduction:
I have prepared a simple example with the erroneous scenario: please see the archive file “errorUpdateFieldsWithDecimalSeparator.zip”. errorUpdateFieldsWithDecimalSeparator.zip (11.2 KB)
At initial startup, input.docx is read and the 4 placeholders found within it are being replaced as described in “More Details”, the method Documents.UpdateFields() is called and the result is saved to output.docx.
Effect on our customers:
Due to the software being used in Germany, it will used with German number formatting. Due to the described bug, our customers cannot rely on our reports to contain correctly calculated data.
Solution or workaround possible?
Is there another way to implement this functionality as intended without changing the input data values? Is there another way for me to refresh the document correctly without having to do it manually after generation in Word? Maybe there is a field option or another configuration that I missed somewhere? Or is the described behaviour an actual bug in Aspose and I can expect it to be corrected soon in future builds?
I would be grateful for a swift solution to my problem. Thank you in advance!
Eudemonia Solutions AG