https://bugs.kde.org/show_bug.cgi?id=267350
Ross Boylan <ross.boy...@ucsf.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ross.boy...@ucsf.edu
--- Comment #51 from Ross Boylan <ross.boy...@ucsf.edu> ---
(In reply to lutz.wrage from comment #50)
> Is there any use case that justifies storing form data in
> ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in
> the pdf itself?
> It seems to me that there isn't.
While I consider the current behavior undesirable, it does have its advantages.
In fact, it's the reason I decided to use okular for my taxes. Here's the use
case:
1. Generate some forms automatically (e.g., opentaxsolver computes my taxes and
fills in government forms).
2. Resulting forms require some manual tweaks (e.g., check boxes, fill in
additional fields).
3. Discover forms need to be regenerated to correct a mistake. Modify inputs
and return to 1.
In this scenario, the work in 2 is lost if the results have been stored in the
pdf, but is retained if the values are stored elsewhere, as okular currently
does. Even if the pdf in 2 is saved under a different name, so that the
results are not literally lost, one must manually identify the changed
information and reenter it.
There is another scenario in which the recreation of the information is less
desirable. If some of the manually entered information in 2 depends on the
values from 1, e.g., you manually enter line 55 as a copy of line 32 but the
automatically generated line 32 changes, then the previous manual data may be
invalid.
--
You are receiving this mail because:
You are watching all bug changes.
