Created attachment 161696 [details] various input field combinations showing the error. STEPS TO REPRODUCE 1. Open the attached document. 2. Go to the second page and enter the value "133.34" in "gross amount in NOK field" OBSERVED RESULT Withholding tax 25% is calculated not properly => 33,335.00 EXPECTED RESULT Should be 33.33 The same applies to the value 133.35 -> the 10% value is not properly calculated. If i enter 133.33 the value is calcluated properly for 25% and 10% SOFTWARE/OS VERSIONS Linux/KDE Plasma: Tuxedo OS (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION
Created attachment 161697 [details] PDF document with the problem.
This seems to happen only in locales with a comma as decimal separator. It breaks when the string "33.335" is passed to JSUtil::stringToNumber(), which results in the number 33335 in a locale with a comma decimal separator, rather than the expected 33.335, ie. this happens for numbers where the conversion is ambiguous between different locales.
Here the sake of completeness - my kde sponsored work entry: https://discuss.kde.org/t/bug-fix-fixing-okular-js-form-calculation-problems/5495
The strange thing is also, that it is not consistent 133.33 -> both 25% and 10% are properly calculated 133.34 -> 25% is calculated wrong 133.35 -> 10% is calculated wrong 133.36 -> both 25% and 10% are properly calculated => The decimal separator and the thousand separator are displayed properly when you just enter "1000" and leave the field. Why the calculation does not work for some numbers i do not understand.
It only triggers when the result has exactly three decimals, as only that produces a string that can be misinterpreted as a value with a dot as group separator instead of decimal separator. This probably isn't even terribly hard to fix, the problem is I am not finding the involved methods in the PDF JS API spec to know how exactly those are supposed to behave.
Are you asking about sepStyle in AFNumber_Format? According to https://acrobatusers.com/forum/javascript/setting-number-format-text-field/ sepStyle = separator style 0 = 1,234.56 1 = 1234.56 2 = 1.234,56 3 = 1234,56
(In reply to Albert Astals Cid from comment #6) > Are you asking about sepStyle in AFNumber_Format? The output part of that is clear I think (and the implementation matches that), the question is how the input should be interpreted in case of that being a string rather than a number. The current implementation is using the current locale format first, and then the alternate format. Unconditionally using the English format would probably fix this, but the current logic presumably didn't happen by accident, so there must be more to this.
The internet says it is a localized number pdfium and pdf.js say "it doesn't matter, just replace the , to . and parse that" (with the understanding that there's no thousand separators i guess)
A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/832
(In reply to Albert Astals Cid from comment #8) > The internet says it is a localized number > > pdfium and pdf.js say "it doesn't matter, just replace the , to . and parse > that" (with the understanding that there's no thousand separators i guess) Indeed, assuming there are no group separators for all string to number conversions fixes this.
The form field has a AFNumber_Keystroke(2, 0, 0, 0, "", true) keystroke script (that Okular doesn't implement, which is another bug in itself) This means . is decimal and , is thousand separator. Acrobat and Firefox don't even let me type in a comma, Chromium treats it as a decimal separator.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/914
A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/992