Calculation of number fields with only dot separator (German Locale) is incorrect


Error Description:
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 “”. (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!

Best regards,
Alexander Rosenberg
Eudemonia Solutions AG

We have tested the scenario and managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSJAVA-2665. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.


have you got a status of the Bug. Even if the Bug looks small, we can not use Aspose in this version. We had and have to use an older version of Aspose.

Due to the fact, that we need it for another software - but there we can not use it neither - it would be great to have a present status or plan. Here I stopped the order process.

Thank you

Tina Püthe
BMS Consulting GmbH

@TinaPuethe Unfortunately, the issue is not resolved yet. I have asked the responsible developer to provide more information. Once I get response I will share it with you. Please accept our apologizes for inconvenience.

1 Like

Hey @alexey.noskov

did you get an answer from the responsible developer. I would be very glad.

@TinaPuethe The issue is currently planned to be resolved in the next 22.3 version of Aspose.Words for Java, which will be available at the beginning of the next month. But please note, this is a rough estimate and it can be shifted.

1 Like

Hi @alexey.noskov, @sergey.lobanov, @tahir.manzoor

22.3 is out, but I didn’t find any fix of WORDSJAVA-2665 there. Is that correct? Will this issue be fixed in 22.4 for sure?

Best regards,
Alexander Rosenberg
Eudemonia Solutions AG (On behalf of BMS Consulting GmbH)

@Alex-Reporter Unfortunately, WORDSJAVA-2665 is not yet resolved. Currently it is planned to be fixed before the next 22.4 release. But as I already mentioned this is a rough estimate and you cannot 100% rely on it. Please accept our apologized for your inconvenience.

The issues you have found earlier (filed as WORDSJAVA-2665) have been fixed in this Aspose.Words for Java 22.4 update.

Good news. I’ll test it and write the status here. Thank you very much.

1 Like

Thank you very much. Now works correctly.

1 Like