Changeset View
Standalone View
core/script/builtin.js
Show All 21 Lines | 19 | { | |||
---|---|---|---|---|---|
22 | if ( cFunction === "PRD" ) | 22 | if ( cFunction === "PRD" ) | ||
23 | { | 23 | { | ||
24 | ret = 1; | 24 | ret = 1; | ||
25 | } | 25 | } | ||
26 | 26 | | |||
27 | for (i = 0; i < cFields.length; i++) | 27 | for (i = 0; i < cFields.length; i++) | ||
28 | { | 28 | { | ||
29 | var field = Doc.getField( cFields[i] ); | 29 | var field = Doc.getField( cFields[i] ); | ||
30 | var val = Number( field.value ); | 30 | var val = util.stringToNumber( field.value ); | ||
31 | 31 | | |||
32 | if ( cFunction === "SUM" || cFunction === "AVG" ) | 32 | if ( cFunction === "SUM" || cFunction === "AVG" ) | ||
33 | { | 33 | { | ||
34 | ret += val; | 34 | ret += val; | ||
35 | } | 35 | } | ||
36 | else if ( cFunction === "PRD" ) | 36 | else if ( cFunction === "PRD" ) | ||
37 | { | 37 | { | ||
38 | ret *= val; | 38 | ret *= val; | ||
Show All 14 Lines | |||||
53 | } | 53 | } | ||
54 | } | 54 | } | ||
55 | 55 | | |||
56 | if ( cFunction === "AVG" ) | 56 | if ( cFunction === "AVG" ) | ||
57 | { | 57 | { | ||
58 | ret /= cFields.length; | 58 | ret /= cFields.length; | ||
59 | } | 59 | } | ||
60 | 60 | | |||
61 | event.value = util.numberToString( ret, "g", 32 ); | ||||
62 | } | ||||
63 | | ||||
64 | | ||||
65 | /** AFNumber_Format | ||||
66 | * | ||||
67 | * Formats event.value based on parameters. | ||||
68 | * | ||||
69 | * Parameter description based on Acrobat Help: | ||||
70 | * | ||||
71 | * nDec is the number of places after the decimal point. | ||||
72 | * | ||||
73 | * sepStyle is an integer denoting whether to use a separator | ||||
74 | * If it is 1 comma should be used. | ||||
75 | * If it is 2 a dot should be used. | ||||
76 | * The decimal seperator is changed accordingly. | ||||
77 | * | ||||
78 | * nexStyle is the formatting used for negative numbers: - not implemented. | ||||
79 | * 0 = MinusBlack | ||||
80 | * 1 = Red | ||||
81 | * 2 = ParensBlack | ||||
82 | * 3 = ParensRed | ||||
83 | * | ||||
84 | * currStyle is the currency style - not used. | ||||
85 | * | ||||
86 | * strCurrency is the currency symbol. | ||||
87 | * | ||||
88 | * bCurrencyPrepend is true to prepend the currency symbol; | ||||
89 | * false to display on the end of the number. | ||||
90 | */ | ||||
91 | function AFNumber_Format( nDec, sepStyle, negStyle, currStyle, strCurrency, bCurrencyPrepend ) | ||||
aacid: Is AFNumber_Format always for currencies? The name seems to make it more about numbers but then… | |||||
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. aheinecke: No, using to currency is just a trick! :-) The aim is to use a nice function that offers a… | |||||
aacid: QLocale::toString ? | |||||
aheinecke: *facepalm* I thought that didn't do separators..... | |||||
92 | { | ||||
93 | if ( !event.value ) | ||||
94 | { | ||||
95 | return; | ||||
96 | } | ||||
97 | | ||||
98 | var ret; | ||||
99 | var localized = util.stringToNumber( event.value ); | ||||
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? aacid: Not having a document to test makes this a bit harder, but let's say i write a number in a form… | |||||
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: FieldFormat.pdf14 KBDownload
Only the first three lines work in okular as they use the number format. Another example would be: aheinecke: I'm not sure I understand the question. I understand it that you are concerned that the actual… | |||||
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? aheinecke: Noticed while thinking about save/load of a formatted form that the behavior you are concerned… | |||||
Can you try what adobe reader does? If it behaves the same it's more than fine aacid: 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: FieldFormat_filled.pdf16 KBDownload aheinecke: Acrobat saves the "internal text" as the annotation value and the formatted text in the… | |||||
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? aacid: I see, Adobe saves on the appearance stream the "visual" representation rounded and with the… | |||||
100 | | ||||
101 | if ( sepStyle === 2 ) | ||||
102 | { | ||||
103 | // Use de_DE as the locale for the dot seperator format | ||||
104 | ret = util.numberToString( localized, "f", nDec, 'de_DE' ); | ||||
105 | } | ||||
106 | else | ||||
107 | { | ||||
108 | // Otherwise US | ||||
109 | ret = util.numberToString( localized, "f", nDec, 'en_US' ); | ||||
110 | } | ||||
111 | | ||||
112 | if ( sepStyle === 0 ) | ||||
113 | { | ||||
114 | // No seperators. Remove all commas from the US format. | ||||
115 | ret.replace( /,/g, '' ); | ||||
116 | } | ||||
117 | | ||||
118 | if ( strCurrency ) | ||||
119 | { | ||||
120 | if ( bCurrencyPrepend ) | ||||
121 | { | ||||
122 | ret = strCurrency + ret; | ||||
123 | } | ||||
124 | else | ||||
125 | { | ||||
126 | ret = ret + strCurrency; | ||||
127 | } | ||||
128 | } | ||||
129 | | ||||
61 | event.value = ret; | 130 | event.value = ret; | ||
62 | } | 131 | } |
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?