Is AFNumber_Format always for currencies? The name seems to make it more about numbers but then the parameters confuse me a little 😆

So i am wondering if we should be always calling toCurrency() or maybe only when strCurrency is passed? and if not using a different formatting function that is not for currency?

No, using to currency is just a trick! :-) The aim is to use a nice function that offers a number format with separators, and decimal handling with rounding and precision.

If sepStyle is 0 then we just remove the currency seperators.

If you have a suggestion for a Qt function that better matches the behavior I'm all for it. But from reading the AF_NumberFormat docs I thought" ok QLocale::toCurrency is the best match" and we can just remove the seperators if sepstyle is zero.

QLocale::toString ?

Not having a document to test makes this a bit harder, but let's say i write a number in a form, the form then changes that number to have dots as separator format and then i just go and add a number at the beginning/end of the "text" of that form. When it comes back here stringToNumber will expect commas and not dots and then everything will break?

I'm not sure I understand the question. I understand it that you are concerned that the actual value of the field is changed by formatting and the user is then confused if he mixes the format when entering additional values.

The trick for that is that the number is not actually changed. As soon as you focus in on the text field the text will change to the actual value. This is also what Acrobat does.

So if you enter with dots but the form want's commas the number is transformed according to your locale for formatting. But as soon as you edit it to add more text it will be changed right back to what you originally entered.

Here is an example that has most "predefined" format settings:

Only the first three lines work in okular as they use the number format.

Another example would be:
https://www.pbeakk.de/fileadmin/redakteure/contents/PDF/Formulare/form_01.pdf

Should just the calculate localize the number?

Acrobat does not do this. In Acrobat the result here is "6000".

But I think that for a KDE / Qt Application it is the correct behavior. As the number format can be set by the user through System Settings and we should respect that here when we convert a number to a string.

It is likely IMO that this is not a real world problem anyway as most forms with calculated values will have explicit number format functions.

Noticed while thinking about save/load of a formatted form that the behavior you are concerned about happens when we save and load. Because only the text is saved and not the internal text.

I doubt that this will be a huge issue though as you mostly fill out form fields once and if you save / load a filled form you probably don't remember what you had filled as "internal" value previously. But it's indeed confusing and a bad user experience in that case.

Do you have an Idea how we could save the internal text?

Can you try what adobe reader does? If it behaves the same it's more than fine

Acrobat saves the "internal text" as the annotation value and the formatted text in the "object"

To clarify (As I don't really know what the "object" is properly called):

If I enter "1234.56444" in a field that formats it as "$ 1,234.56" I find the following in the pdf:

<</BBox [ 0 0 134.042 17.2125 ]/FormType 1/Length 111/Matrix [ 1 0 0 1 0 0 ]/Resources <</Font <</Helv 36 0 R>>/ProcSet [ /PDF /Text ]>>/Subtype /Form/Type /XObject>>stream
/Tx BMC 
q
1 1 132.0416 15.2125 re
W
n
BT
/Helv 12 Tf
0 g
2 4.155 Td
($ ) Tj
9.996 0 Td
(1,234.56) Tj
ET
Q
EMC

endstream
endobj

And:

<<
	/AA <<
		/F 55 0 R
		/K 56 0 R
	>>
	/AP <<
		/N 76 0 R
	>>
	/DA (/Helv 12 Tf 0 g)
	/F 4
	/FT /Tx
	/MK <<
	>>
	/P 15 0 R
	/Rect [ 121.683 763.617 255.724 780.829 ]
	/Subtype /Widget
	/T (us_currency_fmt)
	/Type /Annot
	/V (1234.56444)
>>

Which leads to this behavior (which is IMO Ok) in okular:

I don't think that there is API in poppler to set the fields text to a different value then the value of the annotation. My preference would be to say for now that the behavior of save/load is not perfect but it's usable. A user will probably be annoyed once but afterwards have learned how it behaves.

P.S. Here is the document as saved by Acrobat DC:

I see, Adobe saves on the appearance stream the "visual" representation rounded and with the dollar while in the actual annotation saves the "real" value, with this patch, what do we do? Save the "visual" representation in both?