[Okular-devel] [Bug 267350] New: filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Warren Turkal]

https://bugs.kde.org/show_bug.cgi?id=267350

Summary: filling out a PDF form saves data to some file i
~/.kde/share/apps/okular/docdata/
Product: okular
Version: 0.11.1
Platform: Debian unstable
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: PDF backend
AssignedTo: okular-devel at kde.org
ReportedBy: wt at penguintechs.org


Created an attachment (id=57582)
--> (http://bugs.kde.org/attachment.cgi?id=57582)
IRS form W9

Version: 0.11.1 (using KDE 4.5.3)
OS: Linux

I just realized that Okular is storing my form data in a file that is not the
PDF itself. This file is hard to find and means that my social security number
is stored in some random file on my machine if I fill out an IRS form W9 with
Okular. This seems less than ideal from a UX perspective.

I could not find a way to delete the data short of deleting the files from the
command line. Not storing the data with the PDF is really user hostile in my
opinion.

Also, when I "Save As..." a PDF with filled out forms, only the first field
appears to be saved in the new PDF. For the record, Evince appears to have this
same bug. This may be an indication of a bug in the poppler library.

Reproducible: Always

Steps to Reproduce:
1. Open fw9.pdf IRS form.
2. View forms
3. Type in data
4. Close Okular.
5. look in ~/.kde/share/apps/okular/docdata/

Actual Results:
There are files containing potentially private data in that directory, and it's
hard for a casual user to delete them.

Expected Results:
The user should be able to "Save as..." to a new file and just have a copy of
the PDF with the filled in form data.

OS: Linux (x86_64) release 2.6.37-1-amd64
Compiler: cc

[Jackson Peacock]

https://bugs.kde.org/show_bug.cgi?id=267350


Jackson Peacock <pickled.kde at pepperedpeacock.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |pickled.kde at pepperedpeacock
| |.org




--- Comment #1 from Jackson Peacock <pickled kde pepperedpeacock org> 2011-04-04 03:11:36 ---
I just noticed the same issue. I had stored some filled out forms on an
encrypted drive. I ran into a bug where the fields I entered didn't weren't
being displayed after being saved (not even an empty field). I figured the file
had been corrupted so I copied the original blank form over the filled out one.
When I opened it all the information I had entered into the form was there
despite the file having been overwritten. After looking around I found it had
been written to .kde/share/apps/okular/docdata - on an unencrypted drive. This
was quite startling to me and not what I expected.

I can understand if there are limitations to the PDF format that prevent you
from storing the data in the PDF file itself, however you should at least
inform the user of where the data is being stored before writing it.
Preferably, it should be stored in the same directory as the PDF as well.

[Jackson Peacock]

https://bugs.kde.org/show_bug.cgi?id=267350





--- Comment #2 from Jackson Peacock <pickled kde pepperedpeacock org> 2011-04-10 20:04:21 ---
Another limitation of doing it this way is that it appears impossible to have
multiple copies of the same form filled out differently, even if saved in
different directories. For example, I filled out my tax forms, and then created
a new directory with the copied blank forms to do my girlfriend's taxes.
However, when I opened them they had my value stored in them.

The workaround was to rename the forms and then edit them, but it would match
user expectations better if each copy of the form had it's own set of values.

Finally, I do think the priority on this bug should be higher as it relates to
user privacy/security.

[jordonwii]

https://bugs.kde.org/show_bug.cgi?id=267350


jordonwii at gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jordonwii at gmail.com




--- Comment #3 from <jordonwii gmail com> 2012-01-05 05:26:15 ---
Agree with #2. I know the devs are aware of this because there are other issues
regarding the opening files and having the form remain being filled out
(intentional feature). However, unsure if they are aware of the security
implications of this. Developers have any comment?

[Dan Armbrust]

Post by Warren Turkal
https://bugs.kde.org/show_bug.cgi?id=267350
--- Comment #1 from Jackson Peacock <pickled kde pepperedpeacock org> 2011-04-04 03:11:36 ---
I just noticed the same issue. I had stored some filled out forms on an
encrypted drive. I ran into a bug where the fields I entered didn't weren't
being displayed after being saved (not even an empty field). I figured the file
had been corrupted so I copied the original blank form over the filled out one.
When I opened it all the information I had entered into the form was there
despite the file having been overwritten. After looking around I found it had
been written to .kde/share/apps/okular/docdata - on an unencrypted drive. This
was quite startling to me and not what I expected.
I can understand if there are limitations to the PDF format that prevent you
from storing the data in the PDF file itself, however you should at least
inform the user of where the data is being stored before writing it.
Preferably, it should be stored in the same directory as the PDF as well.
--- Comment #2 from Jackson Peacock <pickled kde pepperedpeacock org> 2011-04-10 20:04:21 ---
Another limitation of doing it this way is that it appears impossible to have
multiple copies of the same form filled out differently, even if saved in
different directories. For example, I filled out my tax forms, and then created
a new directory with the copied blank forms to do my girlfriend's taxes.
However, when I opened them they had my value stored in them.
The workaround was to rename the forms and then edit them, but it would match
user expectations better if each copy of the form had it's own set of values.
Finally, I do think the priority on this bug should be higher as it relates to
user privacy/security.
--- Comment #3 from ?<jordonwii gmail com> ?2012-01-05 05:26:15 ---
Agree with #2. I know the devs are aware of this because there are other issues
regarding the opening files and having the form remain being filled out
(intentional feature). However, unsure if they are aware of the security
implications of this. Developers have any comment?

I, and several others have pointed this out to the developers of
okular nearly 2 years ago.

They are blind, naive, and dare I say foolish. They call this a
"feature" and refuse to acknowledge that it creates security holes all
over the place. They have shown no desire to even take the report
seriously.

http://mail.kde.org/pipermail/okular-devel/2010-February/006386.html

Meanwhile, anyone that has ever used okular to fill out a form with
sensitive information has had that information dumped, in clear text,
onto whatever computer they happened to be using. Without their
knowledge, or permission.

KDE shouldn't even include this program until they fix this.

It's a bad, bad, bad design. Shame on the okular developers for
continuing to ignore the problem.

[Burkhard Lück]

Post by Dan Armbrust
I, and several others have pointed this out to the developers of
okular nearly 2 years ago.

I, and several others use okular compiled from sources since 3.9.x and from
distro packages since around kde 4.2/3 for our daily work to earn our money.

For me Okular is one of the KDE appclications I can't miss in my daily work.

[Albert Astals Cid]

Post by Dan Armbrust

Post by Warren Turkal
https://bugs.kde.org/show_bug.cgi?id=267350
--- Comment #1 from Jackson Peacock <pickled kde pepperedpeacock org>
2011-04-04 03:11:36 --- I just noticed the same issue. I had stored some
filled out forms on an encrypted drive. I ran into a bug where the fields
I entered didn't weren't being displayed after being saved (not even an
empty field). I figured the file had been corrupted so I copied the
original blank form over the filled out one. When I opened it all the
information I had entered into the form was there despite the file having
been overwritten. After looking around I found it had been written to
.kde/share/apps/okular/docdata - on an unencrypted drive. This was quite
startling to me and not what I expected.
I can understand if there are limitations to the PDF format that prevent
you from storing the data in the PDF file itself, however you should at
least inform the user of where the data is being stored before writing
it. Preferably, it should be stored in the same directory as the PDF as
well.
--- Comment #2 from Jackson Peacock <pickled kde pepperedpeacock org>
2011-04-10 20:04:21 --- Another limitation of doing it this way is that
it appears impossible to have multiple copies of the same form filled out
differently, even if saved in different directories. For example, I
filled out my tax forms, and then created a new directory with the copied
blank forms to do my girlfriend's taxes. However, when I opened them they
had my value stored in them.
The workaround was to rename the forms and then edit them, but it would
match user expectations better if each copy of the form had it's own set
of values.
Finally, I do think the priority on this bug should be higher as it
relates to user privacy/security.
--- Comment #3 from <jordonwii gmail com> 2012-01-05 05:26:15 ---
Agree with #2. I know the devs are aware of this because there are other
issues regarding the opening files and having the form remain being
filled out (intentional feature). However, unsure if they are aware of
the security implications of this. Developers have any comment?

I, and several others have pointed this out to the developers of
okular nearly 2 years ago.
They are blind, naive, and dare I say foolish.

You would not dare to say this in my face, so in the future do yourself a
favour and next time you write an email think if you would say the things you
are writing in person.

And since you're being agressive you are not worth an answer, or are you of
that part of people that think than insulting someone will get you a better
treatment than not insulting him?

Cheers,
Albert

Post by Dan Armbrust
They call this a
"feature" and refuse to acknowledge that it creates security holes all
over the place. They have shown no desire to even take the report
seriously.
http://mail.kde.org/pipermail/okular-devel/2010-February/006386.html
Meanwhile, anyone that has ever used okular to fill out a form with
sensitive information has had that information dumped, in clear text,
onto whatever computer they happened to be using. Without their
knowledge, or permission.
KDE shouldn't even include this program until they fix this.
It's a bad, bad, bad design. Shame on the okular developers for
continuing to ignore the problem.
_______________________________________________
Okular-devel mailing list
Okular-devel at kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

[Dan Armbrust]

Post by Albert Astals Cid
You would not dare to say this in my face, so in the future do yourself a
favour and next time you write an email think if you would say the things you
are writing in person.
And since you're being agressive you are not worth an answer, or are you of
that part of people that think than insulting someone will get you a better
treatment than not insulting him?
Cheers,
?Albert

I stopped being nice about this when the developers ignored the report
2 years ago.

They continue to show no respect for their users at all, by allowing
this stupid "feature" to exist.

Meanwhile, countless unsuspecting users are open to the loss of their
personal information, without their knowledge. The developers have
earned the mild "insults" I've tossed their way, and many more on top
of that for failing their users.

If Adobe did something like this, the class action lawsuit would put
them out of business.

[Albert Astals Cid]

Post by Dan Armbrust

Post by Albert Astals Cid
You would not dare to say this in my face, so in the future do yourself a
favour and next time you write an email think if you would say the
things you are writing in person.
And since you're being agressive you are not worth an answer, or are you
of that part of people that think than insulting someone will get you a
better treatment than not insulting him?
Cheers,
Albert

I stopped being nice about this when the developers ignored the report
2 years ago.
They continue to show no respect for their users at all, by allowing
this stupid "feature" to exist.
Meanwhile, countless unsuspecting users are open to the loss of their
personal information, without their knowledge. The developers have
earned the mild "insults" I've tossed their way, and many more on top
of that for failing their users.
If Adobe did something like this, the class action lawsuit would put
them out of business.

Want me to unsubscribe you from the list? Reached this point in what the only
thing you want to do is harass me i think it is the only sensible thing to do.

Albert

Post by Dan Armbrust
_______________________________________________
Okular-devel mailing list
Okular-devel at kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

[Dan Armbrust]

Post by Albert Astals Cid
Want me to unsubscribe you from the list? Reached this point in what the only
thing you want to do is harass me i think it is the only sensible thing to do.
Albert

Now _there_ is a mature response. Users report a serious data
security issue with product. Developers stick their fingers in their
ears and go "la la la".

Users get annoyed with developers, toss a mild insult their way to get
their attention, and developers just silence the users. Go back to
sticking their fingers in their ears and going "la la la".

The _sensible_ thing for you to do is say "Thanks for reporting this
security issue! Sorry we missed it / didn't think about that."

Instead, you continue to pretend the problem doesn't exist.

Any any computer in the world that is configured as a public terminal
- say - in a library - where people download tax forms, fill them in
and print them continues to dump peoples personal data into a clear
text file, without their knowledge or authorization. And anyone else
can come along and take that information.

Good job. Hope you are proud of yourselves. If you get satisfaction
over ejecting me from the mailing list for pointing out the absurdity
of your position, have fun.

[Albert Astals Cid]

Post by Dan Armbrust

Post by Albert Astals Cid
Want me to unsubscribe you from the list? Reached this point in what the
only thing you want to do is harass me i think it is the only sensible
thing to do.
Albert

Now _there_ is a mature response. Users report a serious data
security issue with product. Developers stick their fingers in their
ears and go "la la la".

Not true, i never said it is not a problem, and if i said it i was wrong, it
is a problem, happy? Okular has 208 open bugs, what makes you think your bug
is the one that should be fixed first?

Post by Dan Armbrust
Users get annoyed with developers, toss a mild insult their way to get
their attention, and developers just silence the users.

This is a development channel as the name of the list implies, if you are not
going to *help* with the development, you are more than welcome to leave.

Post by Dan Armbrust
Go back to sticking their fingers in their ears and going "la la la".
The _sensible_ thing for you to do is say "Thanks for reporting this
security issue! Sorry we missed it / didn't think about that."

Sorry, I can't say that, i know it exists, I've known it for ages, i just
don't feel it is the next think i have to do in my life (next thing is getting
my Kindle and reading some stuff), if you think it is important, do it
yourself or get some money and hire someone to fix it, i know a few KDE devels
willing to take money to fix stuff.

Post by Dan Armbrust
Any any computer in the world that is configured as a public terminal
- say - in a library - where people download tax forms, fill them in
and print them continues to dump peoples personal data into a clear
text file, without their knowledge or authorization. And anyone else
can come along and take that information.

This is free software and as you can read in the GPLv2 license "This program
is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE."

Post by Dan Armbrust
Good job. Hope you are proud of yourselves. If you get satisfaction
over ejecting me from the mailing list for pointing out the absurdity
of your position, have fun.

What i did:
I fixed a few bugs and did some free software code, helped debug some
problems with KDE translations

What you did:
You insulted me, with the possible outcome of less bugs fixed and less free
software code going into the world tomorrow

I am proud of myself, are you?

Albert

Post by Dan Armbrust
_______________________________________________
Okular-devel mailing list
Okular-devel at kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

[Dan Armbrust]

Post by Albert Astals Cid
Sorry, I can't say that, i know it exists, I've known it for ages, i just
don't feel it is the next think i have to do in my life (next thing is getting
my Kindle and reading some stuff), if you think it is important, do it
yourself or get some money and hire someone to fix it, i know a few KDE devels
willing to take money to fix stuff.

So, you have proven that you don't take a security issue seriously.
Are there any other developers that do?

The easy fix is to disable this feature until it can be redeveloped
with some thought about proper handling of peoples data.

But I can't seem to convince Albert that this is anything more than a
run-of-the-mill bug, or even a feature request.

Post by Albert Astals Cid

Any computer in the world that is configured as a public terminal
- say - in a library - where people download tax forms, fill them in
and print them continues to dump peoples personal data into a clear
text file, without their knowledge or authorization. ?And anyone else
can come along and take that information.

This is free software and as you can read in the GPLv2 license "This program
is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE."

Yeah. I'm sure that will make the victims of identity theft feel a lot better.

[John McCabe-Dansted]

On Wed, Jan 11, 2012 at 7:44 AM, Dan Armbrust

Post by Dan Armbrust
So, you have proven that you don't take a security issue seriously.

To be fair, fixing this bug wouldn't stop sensitive information
appearing in swap. Sensitive information also has a tendency to appear
in /tmp and /var as well. The EFF recommends full disk encryption,
which would stop this appearing in clear text anywhere.

Post by Dan Armbrust
The easy fix is to disable this feature until it can be redeveloped
with some thought about proper handling of peoples data.

Iirc, last time I used this feature it wouldn't let me print the
annotations, and due to the policy of storing the annotations in a
non-standard format other pdf annotation software couldn't recover my
annotations. I ended up printing a screenshot. Having a warning that
this annotation feature was likely to eat my homework and dump it in
an unencrypted partition would've been nice.

[Albert Astals Cid]

El Dimecres, 11 de gener de 2012, a les 08:58:28, John McCabe-Dansted va

Post by John McCabe-Dansted
On Wed, Jan 11, 2012 at 7:44 AM, Dan Armbrust

Post by Dan Armbrust
So, you have proven that you don't take a security issue seriously.

To be fair, fixing this bug wouldn't stop sensitive information
appearing in swap. Sensitive information also has a tendency to appear
in /tmp and /var as well. The EFF recommends full disk encryption,
which would stop this appearing in clear text anywhere.

And considering we are talking of the "public library scenario", you have to
take into account key loggers, CUPS spool loggers, RAM analyzers, etc. too.

Post by John McCabe-Dansted

Post by Dan Armbrust
The easy fix is to disable this feature until it can be redeveloped
with some thought about proper handling of peoples data.

Iirc, last time I used this feature it wouldn't let me print the
annotations,

Annotations and forms have a different implemented feature set, as far as i
remember forms contents printing is implemented.

Albert

Post by John McCabe-Dansted
and due to the policy of storing the annotations in a
non-standard format other pdf annotation software couldn't recover my
annotations. I ended up printing a screenshot. Having a warning that
this annotation feature was likely to eat my homework and dump it in
an unencrypted partition would've been nice.

[Lydia Pintscher]

Hi,

---------- Forwarded message ----------
From:?Dan Armbrust <daniel.armbrust.list at gmail.com>
To:?bug-control at bugs.kde.org, Okular development <okular-devel at kde.org>, jordonwii at gmail.com, pickled.kde at pepperedpeacock.org, kde at mail.kde.org
Date:?Mon, 09 Jan 2012 15:57:01 -0600
Subject:?Re: [Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

Post by Warren Turkal
https://bugs.kde.org/show_bug.cgi?id=267350
--- Comment #1 from Jackson Peacock <pickled kde pepperedpeacock org> ?2011-04-04 03:11:36 ---
I just noticed the same issue. I had stored some filled out forms on an
encrypted drive. I ran into a bug where the fields I entered didn't weren't
being displayed after being saved (not even an empty field). I figured the file
had been corrupted so I copied the original blank form over the filled out one.
When I opened it all the information I had entered into the form was there
despite the file having been overwritten. After looking around I found it had
been written to .kde/share/apps/okular/docdata - on an unencrypted drive. This
was quite startling to me and not what I expected.
I can understand if there are limitations to the PDF format that prevent you
from storing the data in the PDF file itself, however you should at least
inform the user of where the data is being stored before writing it.
Preferably, it should be stored in the same directory as the PDF as well.
--- Comment #2 from Jackson Peacock <pickled kde pepperedpeacock org> ?2011-04-10 20:04:21 ---
Another limitation of doing it this way is that it appears impossible to have
multiple copies of the same form filled out differently, even if saved in
different directories. For example, I filled out my tax forms, and then created
a new directory with the copied blank forms to do my girlfriend's taxes.
However, when I opened them they had my value stored in them.
The workaround was to rename the forms and then edit them, but it would match
user expectations better if each copy of the form had it's own set of values.
Finally, I do think the priority on this bug should be higher as it relates to
user privacy/security.
--- Comment #3 from ?<jordonwii gmail com> ?2012-01-05 05:26:15 ---
Agree with #2. I know the devs are aware of this because there are other issues
regarding the opening files and having the form remain being filled out
(intentional feature). However, unsure if they are aware of the security
implications of this. Developers have any comment?

I, and several others have pointed this out to the developers of
okular nearly 2 years ago.
They are blind, naive, and dare I say foolish. ?They call this a
"feature" and refuse to acknowledge that it creates security holes all
over the place. ?They have shown no desire to even take the report
seriously.
http://mail.kde.org/pipermail/okular-devel/2010-February/006386.html
Meanwhile, anyone that has ever used okular to fill out a form with
sensitive information has had that information dumped, in clear text,
onto whatever computer they happened to be using. ?Without their
knowledge, or permission.
KDE shouldn't even include this program until they fix this.
It's a bad, bad, bad design. ?Shame on the okular developers for
continuing to ignore the problem.

Dan, I understand you are frustrated. But this here doesn't help to
solve the problem. In fact it makes it a lot less likely that Albert
or one of the other Okular developers will work on it. So ultimately
you are hurting your case.
Now let's move this forward constructively, please. There are several
ways to do this:
* Work on it yourself if you have the skills.
* Convince someone else to work on it.
* Wait until Albert or one of the other Okular developers finds time
for it. I am sure they have registered by now that this is important
to you.


Cheers
Lydia

[Dan Armbrust]

Post by Lydia Pintscher
Dan, I understand you are frustrated. But this here doesn't help to
solve the problem. In fact it makes it a lot less likely that Albert
or one of the other Okular developers will work on it. So ultimately
you are hurting your case.
Now let's move this forward constructively, please. There are several
* Work on it yourself if you have the skills.
* Convince someone else to work on it.
* Wait until Albert or one of the other Okular developers finds time
for it. I am sure they have registered by now that this is important
to you.
Cheers
Lydia
--
Lydia Pintscher
KDE Community Working Group / KDE e.V. board member
http://kde.org - http://about.me/lydia.pintscher

I'm really sorry that no one reading this thread seems to be able to
comprehend the dis-service that KDE and Ocular are doing to their
users.

Okular is behaving almost as badly as a virus.

This should be treated as a security issue. And it should be handled
as one. And fixed. Quickly.

Instead, we have Albert denying that it is a problem... or, ignoring
is, since hey, there are all of these other ways that people could
steal data, what harm will one more do?
Even if someone else fixed it, he probably wouldn't accept the patch,
since he considers it a "feature".

This bug doesn't impact me. Because I uninstalled Okular 2 years ago,
when I discovered the problem.

This bug impacts everyone else that ever uses Okular - they just don't
know it. So, I'm advocating for them, since no one else seems to
care.

I reported this issue to the developers two years ago.
I even suggested a number of ways that it could be addressed.
The most trivial of fixes would have taken a developer about 2 minutes
- simply turn off the damn "feature" - or redirect it to /dev/null.
But, no one will turn it off.

So, we remain at a stalemate. With Okular behaving like a virus. And
Albert calling it a feature. No one else with the power to fix it
cares, and the users get the shaft.

What a sad state.

[Lydia Pintscher]

On Fri, Jan 13, 2012 at 16:03, Dan Armbrust

Post by Dan Armbrust

Post by Lydia Pintscher
Dan, I understand you are frustrated. But this here doesn't help to
solve the problem. In fact it makes it a lot less likely that Albert
or one of the other Okular developers will work on it. So ultimately
you are hurting your case.
Now let's move this forward constructively, please. There are several
* Work on it yourself if you have the skills.
* Convince someone else to work on it.
* Wait until Albert or one of the other Okular developers finds time
for it. I am sure they have registered by now that this is important
to you.
Cheers
Lydia
--
Lydia Pintscher
KDE Community Working Group / KDE e.V. board member
http://kde.org - http://about.me/lydia.pintscher

I'm really sorry that no one reading this thread seems to be able to
comprehend the dis-service that KDE and Ocular are doing to their
users.
Okular is behaving almost as badly as a virus.

Again: It's obvious you are frustrated, Dan. But this isn't helping us
all solve the issue here.

Post by Dan Armbrust
This should be treated as a security issue. ?And it should be handled
as one. ?And fixed. ?Quickly.

http://www.kde.org/info/security/ has details about security issues
and their handling in KDE.

Post by Dan Armbrust
Instead, we have Albert denying that it is a problem... or, ignoring
is, since hey, ?there are all of these other ways that people could
steal data, what harm will one more do?
Even if someone else fixed it, he probably wouldn't accept the patch,
since he considers it a "feature".

Did you ask if he'd accept a patch by someone else?

Post by Dan Armbrust
This bug doesn't impact me. ?Because I uninstalled Okular 2 years ago,
when I discovered the problem.
This bug impacts everyone else that ever uses Okular - they just don't
know it. ?So, I'm advocating for them, since no one else seems to
care.

All of us here care about KDE. There are however _a lot_ of things to
care about in KDE. Too many of them in fact. This particular issue is
higher on your list than Albert's. That doesn't in itself make either
of you a bad person.

Post by Dan Armbrust
I reported this issue to the developers two years ago.
I even suggested a number of ways that it could be addressed.
The most trivial of fixes would have taken a developer about 2 minutes
- simply turn off the damn "feature" - or redirect it to /dev/null.
But, no one will turn it off.

I assume there is a reason for that?

Post by Dan Armbrust
So, we remain at a stalemate. ?With Okular behaving like a virus. ?And
Albert calling it a feature. ?No one else with the power to fix it
cares, and the users get the shaft.

Please leave out the retorics. Then we can actually try to move this
forward. I'm trying to help you here.


Cheers
Lydia

[Marek Otahal]

https://bugs.kde.org/show_bug.cgi?id=267350

Marek Otahal <markotahal at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |markotahal at gmail.com

[jamesp]

https://bugs.kde.org/show_bug.cgi?id=267350

jamesp at westcoastaerospace.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jamesp at westcoastaerospace.c
| |om

--- Comment #4 from jamesp at westcoastaerospace.com ---
I ran into this problem too recently. In one department at my workplace, I set
up a computer where employees can read PDFs and fill out PDF forms. There is
one particular form that each of them has to fill out every two weeks. I
discovered that I could avoid the problem of each person seeing (and having to
delete) the details entered by the previous person by renaming the pdf file to
a random temporary filename before opening it. Then I realized that by serving
the pdf file from a local webserver, and having them open the pdf from a link
in firefox, I would get the random temporary filename for free without having
to script it. It is certainly a kludge, but it seems pretty usable for now :)

[Andrea Scarpino]

https://bugs.kde.org/show_bug.cgi?id=267350

Andrea Scarpino <andrea at archlinux.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |andrea at archlinux.org

[Lukas Schreiner]

https://bugs.kde.org/show_bug.cgi?id=267350

Lukas Schreiner <lukas at d56355.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |lukas at d56355.de

[Uwe Geuder]

https://bugs.kde.org/show_bug.cgi?id=267350

Uwe Geuder <wfp46n97wf at snkmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |wfp46n97wf at snkmail.com

--- Comment #5 from Uwe Geuder <wfp46n97wf at snkmail.com> ---
Besides form data also annotations were served in that extra docdata xml file.

For annotations this has been fixed recently:
https://bugs.kde.org/show_bug.cgi?id=151614

I haven't had time yet to read the whole lengthy discussion there or to install
the new version to see whether /how it affects form data.

[Marcus Furlong]

https://bugs.kde.org/show_bug.cgi?id=267350

Marcus Furlong <furlongm at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |furlongm at gmail.com

--- Comment #6 from Marcus Furlong <furlongm at gmail.com> ---
Have just been bitten by this as well. The form I returned did not contain any
form data.

A user should reasonably expect that form data is saved with the form, as this
is what other pdf viewers do, and this is what the "File->Save As" option
suggests it does. For a long form that has that has taken the user days to fill
in, this is definitely an unexpected and unwelcome bug.

popper 0.22.1
okular 0.16.0 on kde 4.10

[Marcus Furlong]

https://bugs.kde.org/show_bug.cgi?id=267350

Marcus Furlong <furlongm at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1

--- Comment #7 from Marcus Furlong <furlongm at gmail.com> ---
*** This bug has been confirmed by popular vote. ***

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

Albert Astals Cid <aacid at kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |aacid at kde.org

--- Comment #8 from Albert Astals Cid <aacid at kde.org> ---
Marcus your problem has nothing to do with this bug, Warren is complaining
about the data leakage into his own home folder.

What you are facing has nothing to do with this. So please open a separate bug
about it.

[Warren Turkal]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #9 from Warren Turkal <wt at penguintechs.org> ---
To quote my original description:

Expected Results:
The user should be able to "Save as..." to a new file and just have a copy of
the PDF with the filled in form data.

I believe this is exactly what Marcus was asking for.

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #10 from Albert Astals Cid <aacid at kde.org> ---
Then you used a wrong subject and i decided to ignore this bug, "Save as..."
should and does work here, please, i'm attaching a filled in (just the first
two lines) with okular of the file you attached that opens fine in Adobe Reader
and shows the data

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #11 from Albert Astals Cid <aacid at kde.org> ---
Created attachment 78620
--> https://bugs.kde.org/attachment.cgi?id=78620&action=edit
Filled in file

With "Hola" and "Pepe" in the first two lines

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #12 from Albert Astals Cid <aacid at kde.org> ---
FWIW that filled in file was created with poppler 0.23 and can't be opened with
0.22 or older :-/ But that's a bug of those old versions, you can open it with
Adobe Reader to see it working

[Marcus Furlong]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #13 from Marcus Furlong <furlongm at gmail.com> ---
It's the same bug, just a different title. Instead of saving the form data to
the PDF, it gets saved externally.

Happy to hear it's solved in a newer version of poppler. 0.23 is the
development branch of what will become 0.24?

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #14 from Albert Astals Cid <aacid at kde.org> ---
Oh no, 0.22 works too, i just created it with 0.23 because it was what i had
installed, let me attach one created with 0.22

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #15 from Albert Astals Cid <aacid at kde.org> ---
Created attachment 78638
--> https://bugs.kde.org/attachment.cgi?id=78638&action=edit
Filled file with poppler 0.22

[Marcus Furlong]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #16 from Marcus Furlong <furlongm at gmail.com> ---
The must be something different in our environments then. I'm using opensuse
12.3, okular 0.16.0 on KDE 4.10.0. Is there a compile-time option to enable
this in poppler or okular?

I downloaded your second attachment and I can see the form data you have
entered. I add my own form data and save, and when I close okular and reopen
the same file, the text is there. But my text is saved externally. If I do the
following, the form data reverts to your text

mv morsa.pdf morsa1.pdf
okular morsa1.pdf

and the form data I had saved is only visible in
.kde4/share/apps/okular/docdata/107650.morsa.pdf.xml

[Marek Otahal]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #17 from Marek Otahal <markotahal at gmail.com> ---
Hello, Archlinux, kde 4.10.2, okular 0.16.2, I confirm I can open morsa.pdf and
see the filled in fields(!), file elefante.pdf fails to even open.

@Marcus:
I confirm mv file and open keeps the filled in data. (Note difference between
Save as.., and Save a copy)

Backends here:

$ pacman -Qs poppler
local/poppler 0.22.2-1
PDF rendering library based on xpdf 3.0
$ pacman -Qs ghostscript
local/ghostscript 9.07-1
An interpreter for the PostScript language

ghostscript is mentioned in Okular as backend.

It would be perfect if forms started to work! :)

[Marek Otahal]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #18 from Marek Otahal <markotahal at gmail.com> ---
Created attachment 78649
--> https://bugs.kde.org/attachment.cgi?id=78649&action=edit
pdf with notes and drawing

Btw, if it helps, taking notes (drawing, stamps, highlighting etc) saves
properly. Please verify painting2.pdf
Maybe the forms could be done in same way.

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #19 from Albert Astals Cid <aacid at kde.org> ---
Marcus i can't help you here, i've proven it works as it has worked for a long
time to be honest i should close this bug since it's basically a weird worded
bug and people is just commenting on it with unrelated comments, if it doesn't
work for you, you're doing something wrong or opensuse compiled something
wrong, but not sure how can i help you debug it.

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

Rajiv Gupta <diffgeom at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |diffgeom at gmail.com

--- Comment #20 from Rajiv Gupta <diffgeom at gmail.com> ---
It seems that when I fill out a form with Okular (with poppler 0.22), it opens
in Okular when I rename it or move it to another computer. But no matter what,
it doesn't open in Adobe Reader.

[Yuri Chornoivan]

https://bugs.kde.org/show_bug.cgi?id=267350

Yuri Chornoivan <yurchor at ukr.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |yurchor at ukr.net

--- Comment #21 from Yuri Chornoivan <yurchor at ukr.net> ---
(In reply to comment #20)

Post by Rajiv Gupta
It seems that when I fill out a form with Okular (with poppler 0.22), it
opens in Okular when I rename it or move it to another computer. But no
matter what, it doesn't open in Adobe Reader.

Please use "File -> Save as..." to save filled data with your PDF file.

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #22 from Rajiv Gupta <diffgeom at gmail.com> ---
I used save as, but I think it only happens with some PDF files. The tax form
works perfectly, but I am attaching a file for which the filled out forms only
appear in Okular, but not Adobe Reader.

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #23 from Rajiv Gupta <diffgeom at gmail.com> ---
Created attachment 80639
--> https://bugs.kde.org/attachment.cgi?id=80639&action=edit
File for which forms only appear in Okular, not Adobe Reader

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

Rajiv Gupta <diffgeom at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|diffgeom at gmail.com |

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

Rajiv Gupta <diffgeom at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |diffgeom at gmail.com

[Andrea Scarpino]

https://bugs.kde.org/show_bug.cgi?id=267350

Andrea Scarpino <scarpino at kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|scarpino at kde.org |

[Yuri Chornoivan]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #24 from Yuri Chornoivan <yurchor at ukr.net> ---
FoxIt Reader (under wine) shows filled forms.

It can be a bug in Adobe Reader (tested version XI (11.0.03), also under wine).

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #25 from Rajiv Gupta <diffgeom at gmail.com> ---
I am attaching the same form filled with Adobe.

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #26 from Rajiv Gupta <diffgeom at gmail.com> ---
Created attachment 80647
--> https://bugs.kde.org/attachment.cgi?id=80647&action=edit
Same form filled out in Adobe

This form opens in both Okular and Adobe.

[Fabio D'Urso]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #27 from Fabio D'Urso <fabiodurso at hotmail.it> ---
Created attachment 80666
--> https://bugs.kde.org/attachment.cgi?id=80666&action=edit
XFA-warning

(In reply to comment #23)

Created attachment 80639 [details]
File for which forms only appear in Okular, not Adobe Reader

Yes, it's known issue. Basically that file uses a newer format to store form
data, which is currently unsupported by poppler (and probably won't be for a
long time, because it's very complex).
However, Okular from 4.10 with poppler 0.22 should warn you (see attached
screen), doesn't it?

[Rajiv Gupta]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #28 from Rajiv Gupta <diffgeom at gmail.com> ---
No I don't get that warning (using KDE 4.10.3), but I found a workaround, which
is to print the file to a PDF, which opens with Adobe. And now I'm going to do
a "sudo apt-get purge acroread acroread-bin". (When I installed it 2 days ago,
it created a file located in / called C:\nppdf32Log\debuglog.txt)

[Aaron Wolf]

https://bugs.kde.org/show_bug.cgi?id=267350

Aaron Wolf <wolftune at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |wolftune at gmail.com

--- Comment #29 from Aaron Wolf <wolftune at gmail.com> ---
This is obnoxious. My partner sent me a file with forms filled. I changed them.
There's NO WAY to keep having editable forms and send her back the file with
the changes!

I tried "save as" and still get the old data there. I had to do it as a print,
which means she then manually updates in her program.

This situation is horrible.

[Yuri Chornoivan]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #30 from Yuri Chornoivan <yurchor at ukr.net> ---
(In reply to comment #29)

Post by Aaron Wolf
This is obnoxious. My partner sent me a file with forms filled. I changed
them. There's NO WAY to keep having editable forms and send her back the
file with the changes!
I tried "save as" and still get the old data there. I had to do it as a
print, which means she then manually updates in her program.
This situation is horrible.

This is not the way to report bugs. Please give developers some information
about your system (name and version), version of Okular and version of Poppler
libraries (can be determined with "pdftops -v" command in console or using your
favorite package manager).

BTW, just works here (even for XFA documents if Foxit reader used).

[Aaron Wolf]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #31 from Aaron Wolf <wolftune at gmail.com> ---
(In reply to comment #30)

Post by Yuri Chornoivan
(In reply to comment #29)

Post by Aaron Wolf
This is obnoxious. My partner sent me a file with forms filled. I changed
them. There's NO WAY to keep having editable forms and send her back the
file with the changes!
I tried "save as" and still get the old data there. I had to do it as a
print, which means she then manually updates in her program.
This situation is horrible.

This is not the way to report bugs. Please give developers some information
about your system (name and version), version of Okular and version of
Poppler libraries (can be determined with "pdftops -v" command in console or
using your favorite package manager).
BTW, just works here (even for XFA documents if Foxit reader used).

Sorry, I just assumed this was the same as the original bug, i.e. an
intentional and flawed design. I didn't think this was behaving differently
from intended, I thought the issue was simply that the intention was a bad one.

If you intend it to actually work reasonably (which I'd hope), and it is
something about my system, well: I'm on KXStudio, which is a derivative of
Ubuntu. I'm using standard KDE 4.11.2 and Okular 0.17.2 and pdftops 0.18.4.

To clarify: if I open and change the forms myself, they persist on my machine.
If I send the form as an e-mail to someone else, they lose my form changes. If
I "save as" on my own machine, the new file reverts to the old form data and
loses my changes even on my machine. Note that this is a case where the file I
got from someone else started with some form data already, entered in some
program other than Okular, and I was changing it.

[Yuri Chornoivan]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #32 from Yuri Chornoivan <yurchor at ukr.net> ---
(In reply to comment #31)

Post by Aaron Wolf
(In reply to comment #30)

Post by Yuri Chornoivan
(In reply to comment #29)

Post by Aaron Wolf
This is obnoxious. My partner sent me a file with forms filled. I changed
them. There's NO WAY to keep having editable forms and send her back the
file with the changes!
I tried "save as" and still get the old data there. I had to do it as a
print, which means she then manually updates in her program.
This situation is horrible.

This is not the way to report bugs. Please give developers some information
about your system (name and version), version of Okular and version of
Poppler libraries (can be determined with "pdftops -v" command in console or
using your favorite package manager).
BTW, just works here (even for XFA documents if Foxit reader used).

Sorry, I just assumed this was the same as the original bug, i.e. an
intentional and flawed design. I didn't think this was behaving differently
from intended, I thought the issue was simply that the intention was a bad
one.
If you intend it to actually work reasonably (which I'd hope), and it is
something about my system, well: I'm on KXStudio, which is a derivative of
Ubuntu. I'm using standard KDE 4.11.2 and Okular 0.17.2 and pdftops 0.18.4.
To clarify: if I open and change the forms myself, they persist on my
machine. If I send the form as an e-mail to someone else, they lose my form
changes. If I "save as" on my own machine, the new file reverts to the old
form data and loses my changes even on my machine. Note that this is a case
where the file I got from someone else started with some form data already,
entered in some program other than Okular, and I was changing it.

It seems that poppler libraries in your system are too old (Okular itself is
up-to-date). You need to install at least poppler-0.20 (or better 0.22) to have
reliable forms and annotation editor which can save the data in PDF. Try to
find some PPA with newer version (Debian Sid has 0.18.4, Ubuntu 13.04 has
0.20.5 and Ubuntu 13.10 has 0.24.1). Sorry.

Please take into account that some other applications (e.g. Inkscape) can be
dependent on the old version of poppler, so the safest way is to build and
install libraries on your own (it is not hard at all, so they do not break
anything).

[Aaron Wolf]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #33 from Aaron Wolf <wolftune at gmail.com> ---

Post by Yuri Chornoivan
It seems that poppler libraries in your system are too old (Okular itself is
up-to-date). You need to install at least poppler-0.20 (or better 0.22) to
have reliable forms and annotation editor which can save the data in PDF.
Try to find some PPA with newer version (Debian Sid has 0.18.4, Ubuntu 13.04
has 0.20.5 and Ubuntu 13.10 has 0.24.1). Sorry.
Please take into account that some other applications (e.g. Inkscape) can be
dependent on the old version of poppler, so the safest way is to build and
install libraries on your own (it is not hard at all, so they do not break
anything).

Oh how strange, thank you. I will figure this out! Sorry to have made
assumptions about things?

[esigra]

https://bugs.kde.org/show_bug.cgi?id=267350

esigra at gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |esigra at gmail.com

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

Albert Astals Cid <aacid at kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|0.11.1 |0.19.60

[sparhawk]

https://bugs.kde.org/show_bug.cgi?id=267350

sparhawk <kdebugs at plast.id.au> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |kdebugs at plast.id.au

--- Comment #34 from sparhawk <kdebugs at plast.id.au> ---
I've used "save a copy" accidentally, not realising that this was fundamentally
different to "save as". In a lot of programs these both create a new file, but
the former leaves you editing the original, while the latter allows to keep
editing the newly created file.

Anyway, I've now realised that there is potentially a lot of private data (e.g.
credit card information) stored in plain text on my computer. It seems that
some of the information in ~/.kde/share/apps/okular/docdata/ is about the
last-used zoom/position of documents? How can I find which of these documents
contains form data?

[Yuri]

https://bugs.kde.org/show_bug.cgi?id=267350

Yuri <***@tsoft.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@tsoft.com

--- Comment #35 from Yuri <***@tsoft.com> ---
*** Bug 343852 has been marked as a duplicate of this bug. ***

[Yuri]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #36 from Yuri <***@tsoft.com> ---
Real problem is that okular violates pdf specification: section "8.6.6 Forms
Data Format" of PDF reference:
http://partners.adobe.com/public/developer/en/pdf/PDFReference16.pdf

The standard way to store forms is to write the form data into the special
section in the same pdf file.

Current way is prone to data loss and confusion, because users will send out
the pdf assuming that form is there, when it isn't. Currently form data is
implicitly attached to the current pdf file name, which is counter-intuitive.

[Yuri]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #37 from Yuri <***@tsoft.com> ---
I would put the high priority on this, because the major user visible function
malfunctions due to misimplementation.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

***@kloss.nz changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@kloss.nz

[Albert Astals Cid via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

Albert Astals Cid <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmx.de

--- Comment #38 from Albert Astals Cid <***@kde.org> ---
*** Bug 357741 has been marked as a duplicate of this bug. ***

[Carsten Gräser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

Carsten Gräser <***@math.fu-berlin.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@math.fu-berlin.de

--- Comment #39 from Carsten Gräser <***@math.fu-berlin.de> ---
I also stumbled about the fact that it seems to be impossible to have multiple
instances of the same filled in form under the same file name and got the
impression that "Save as..." does not work. After some experimenting I found
out the problem with "Save as...":

There's two places where form data is stored: .kde/* and the pdf-file itself.
Data is always saved to .kde/* (attached to filename?). If you use "Save as"
it's also stored to the file. The problem is that this is not visible to the
user and that .kde/* seems to have precedence. If you want to fill the same
form twice you can easily run into problems:

Case a: Since form data is visible after closing, reopening, or moving the
file, the user assumes that it's stored inside of the pdf. To fill a form a
second time he copies the filled in form into a new location and changes the
necessary data. Everything seems to work, but if he reopens the original file
all it's data is changed to what he entered in the new place.

Case b: The user is aware that data is stored in the file only if he used "Save
as". After filling the form the first time he uses "Save as". To fill the form
a second time he copies the filled in form into a new location and changes the
necessary data and uses "Save as" again. Now different data is saved in both
versions of the file. But if he opens version 1 again, he sees the changes he
did in version 2. The reason for this is that by changing version 2, the data
in .kde/* is changed and this seems to have precedence when viewing version 1.
If you delete th corresponding file in .kde/* you see what's stored in the
file.

In both cases the user seems to have lost data. In a) this is true, in b) his
data is just not visible.

[Carsten Gräser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #40 from Carsten Gräser <***@math.fu-berlin.de> ---
Since I stumbled about this again: The following minor changes would increase
usability of forms a lot since they make the behaviour of Okular more
transparent.

a) Add a menu entry "save form data" that makes Okular store the data in the
file itself.
b) When the user tries to close a filled in form without explicitly saving it:
Warn the user that the form data is not stores in the file (but only cached
somewhere else) and ask if she/he want's to save now.
c) Always give precedence to data saved in the file itself.

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #41 from Yuri <***@tsoft.com> ---
(In reply to Carsten Gräser from comment #40)

Post by Carsten Gräser via KDE Bugzilla
Since I stumbled about this again: The following minor changes would
increase usability of forms a lot since they make the behaviour of Okular
more transparent.
a) Add a menu entry "save form data" that makes Okular store the data in the
file itself.
b) When the user tries to close a filled in form without explicitly saving
it: Warn the user that the form data is not stores in the file (but only
cached somewhere else) and ask if she/he want's to save now.
c) Always give precedence to data saved in the file itself.

Carsten, the problem is that there is no code that saves to a file. There
should be two choices:
* Saving to a pdf file itself
* Saving to a separate pdf file (according to the pdf spec)
But somebody for some unknown reason implemented writing it in the proprietary
format into ~/.kde/share/apps/okular/docdata/ that makes okular unusable for
filling forms. Nobody needs the function to save forms under ~/.kde

[Carsten Gräser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #42 from Carsten Gräser <***@math.fu-berlin.de> ---
Yuri, this is not correct. Okular can in principle save the data to the pdf.
But the interplay of this with saving to and loading from .kde/... is not very
intuitive.

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #43 from Yuri <***@tsoft.com> ---
(In reply to Carsten Gräser from comment #42)

Post by Carsten Gräser via KDE Bugzilla
Yuri, this is not correct. Okular can in principle save the data to the pdf.
But the interplay of this with saving to and loading from .kde/... is not
very intuitive.

What does it mean "can in principle"? Is the code saving it to the pdf there or
not there? If it is there, can you send the link (line numbers)?

[Carsten Gräser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #44 from Carsten Gräser <***@math.fu-berlin.de> ---
(In reply to Yuri from comment #43)

Post by Yuri via KDE Bugzilla
(In reply to Carsten Gräser from comment #42)

Post by Carsten Gräser via KDE Bugzilla
Yuri, this is not correct. Okular can in principle save the data to the pdf.
But the interplay of this with saving to and loading from .kde/... is not
very intuitive.

What does it mean "can in principle"? Is the code saving it to the pdf there
or not there? If it is there, can you send the link (line numbers)?

I gave a very detailed explanation of "in principle". just try out as described
above.

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #45 from Yuri <***@tsoft.com> ---
(In reply to Carsten Gräser from comment #44)

Post by Carsten Gräser via KDE Bugzilla
I gave a very detailed explanation of "in principle". just try out as
described above.

I don't know what are you talking about. You don't make yourself clear.

[Aaron Wolf via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #46 from Aaron Wolf <***@gmail.com> ---
@Yuri, Carsten was saying that the current Okular behavior *does* save data
directly to the PDF *if* you use "save as" but otherwise not. The problem
remaining is that it also saves to a hidden directory as well, and then
conflicts and security issues can arise from that.

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #47 from Yuri <***@tsoft.com> ---
Ah, I see. I didn't realize the pdf form-saving code was even there. This makes
the situation much better than I thought.

Thanks for clarifying this!

Somebody should just remove the code writing under ~/.kde4/share/apps/okular/

[Enrico Tagliavini via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

Enrico Tagliavini <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Niels Elgaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

Niels Elgaard <***@agol.dk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@agol.dk

--- Comment #48 from Niels Elgaard <***@agol.dk> ---
Today I received a PDF with forms filled in, that I had to forward as a normal
PDF (using "save as" or print to PDF file). Some fields worked as expected. But
some were missing in the resulting PDF.

After quite some time I tried editing every single form field, ending up with
the same values as before, and then printing to to PDF. Then everything
working, i.e. all form fields were saved to the PDF file.

I use Okular 0.25, Platform 4.14.23

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

Albert Astals Cid <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #49 from Albert Astals Cid <***@kde.org> ---
*** Bug 372488 has been marked as a duplicate of this bug. ***

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=267350

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #50 from ***@gmail.com ---
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.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=267350

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zoho.com

[Simon Andric]

https://bugs.kde.org/show_bug.cgi?id=267350

Simon Andric <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Ross Boylan]

https://bugs.kde.org/show_bug.cgi?id=267350

Ross Boylan <***@ucsf.edu> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ucsf.edu

--- Comment #51 from Ross Boylan <***@ucsf.edu> ---
(In reply to lutz.wrage from comment #50)

Post by b***@kde.org
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.

[Ross Boylan]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #52 from Ross Boylan <***@ucsf.edu> ---
I don't want my previous response to be taken as a vote for the status quo.
The behavior I would expect is:

1. If I don't hit save my work disappears.(*) The current application does not
have a save function (as distinct from save as), and I'm pretty sure that if I
fill in a form, exit, and then open the form my old values will still be there.
Worse, if someone else using the same account opens the form, they will see my
info.

2. If I do save (not just save as) my work will be saved with the file.

In this case I might not expect, but would be pleased if
3. there were an option to save the form data to a separate file and restore it
from a separate file. I'd guess such a facility is consistent with the 1600
page XFA spec, though I can't say I know where :)

Because the current behavior violates these expectations, it is a security
risk. Someone's personal information may be exposed in ways unanticipated,
and operations that usually assure security, like not saving a file or deleting
it, will not work. And operations that are expected to reveal info, like
copying/mailing a pdf or operating on it with a different program, may instead
conceal/disappear the information.

(*) Some usability experts argue that "work disappears if I don't save" is not
the expectation of the lay user, and that our current model of "you must save
to keep your work" is aggravating and unintuitive to them. That may well be
correct. But unless the surrounding programs all start behaving this way, this
behavior is undesirable. An application that may be dealing with sensitive
private information is not the place to pioneer new interface models.

[Yuri]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #53 from Yuri <***@tsoft.com> ---
(In reply to Ross Boylan from comment #52)

Post by Ross Boylan
I don't want my previous response to be taken as a vote for the status quo.

Saving form data into the file is the behavior prescribed by pdf specification.
Leaving form files in any other place has so many disadvantages that it doesn't
even make sense to list them.


It's amazing this isn't fixed for 6.5 years now.

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #54 from Albert Astals Cid <***@kde.org> ---
Please, stop complaining, complaining doesn't do anyone any good, we know it
needs improvement and we're working in a fix.

If you want to get it fixed earlier, either volunteer to help with the fix or
hire someone to fix it faster.

[sparhawk]

https://bugs.kde.org/show_bug.cgi?id=267350

we know it needs improvement and we're working in a fix.

To be fair to the other commenters, we hadn't heard anything here for a few
years, so I presumed that the devs were *not* working on a fix. Sometimes KDE
bugs tend to drift around for a few years before being abruptly closed as
"won't fix", so I can understand why people continue to complain.

Also, I was also unaware that you were even a dev until I mouse-overed your
name and saw the @kde.org email address just then. I guess that's a fault of
this website though; a visible dev tag similar to GitHub would be useful.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #56 from Nate Graham <***@zoho.com> ---
Definitely a good idea. Technically I'm a KDE developer too even though I don't
have or use a @kde.org email address. Can you file a bug to that effect on
https://bugs.kde.org/enter_bug.cgi?product=bugs.kde.org?

[Luigi Toscano]

https://bugs.kde.org/show_bug.cgi?id=267350

Luigi Toscano <***@tiscali.it> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@tiscali.it

--- Comment #57 from Luigi Toscano <***@tiscali.it> ---
I'm not sure that highlighting the fact that someone is a KDE devleoper here is
a good idea.
If I comment in a bug of a component which I never touched, I'm not sure why
that comment should have some sort of special marking.

That said, we are off-topic here; the place to discuss this is the
kde-community@ mailing list.

[Michael Weghorn]

https://bugs.kde.org/show_bug.cgi?id=267350

Michael Weghorn <***@posteo.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@posteo.de

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #58 from Albert Astals Cid <***@kde.org> ---
For people that have an idea how to compile and test stuff, please test
https://phabricator.kde.org/D8642

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=267350

Albert Astals Cid <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|CONFIRMED |RESOLVED

--- Comment #59 from Albert Astals Cid <***@kde.org> ---
This won't be anymore the case starting with the Okular that will be part of
KDE Applications 17.12 (aka okular 1.3.0)

[Wren Turkal]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #60 from Wren Turkal <***@penguintechs.org> ---
Hi,

OP here. I wanted to reach out and thank you for fixing this issue much more
comprehensively than I imagined when I originally filled the issue.


Thanks,
wt

[Antony Lee]

https://bugs.kde.org/show_bug.cgi?id=267350

Antony Lee <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Antony Lee]

https://bugs.kde.org/show_bug.cgi?id=267350

Antony Lee <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|***@gmail.com |