D13172: Add AFNumber_Format and l10n AFSimple_Calculate

[Andre Heinecke]

aheinecke added inline comments.

INLINE COMMENTS

> aheinecke wrote in builtin.js:99
> 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:
> 
> F5918086: FieldFormat.pdf <https://phabricator.kde.org/F5918086>
> 
> 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

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?

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D13172

To: aheinecke, aacid
Cc: okular-devel, ngraham, aacid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20180622/be686819/attachment.html>