Saving certain PDF forms corrupts them if they've been filled out.

Created an attachment (id=22494)
Affected PDF.

Saving certain forms after filling them in results in empty PDFs. To reproduce:

Open the attached file in Evince. Fill in some form data. Save the file.

What I expected: The resultant file has size 0.

What I got: The resultant file should contain at least some data.

I'm using poppler 0ed3fd52bb2d3375ed302285b18f076721b8028e, just updated from the repo today. (I also used Cairo 1.8.4 and Evince SVN r3295, but the folks at the GNOME bugtracker assure me that it's a poppler issue.)

This was originally reported on the GNOME bugtracker:

http://bugzilla.gnome.org/show_bug.cgi?id=564268

So you tell cairo and evince versions when reporting a poppler bug but you don't say the poppler version? ;-) Can i have it please?

The poppler version was pulled from git today; the commit ID is specified in the report.

http://cgit.freedesktop.org/poppler/poppler/commit/?id=0ed3fd52bb2d3375ed302285b18f076721b8028e

You should be able to get the exact revision by running "git checkout 0ed3fd52bb2d3375ed302285b18f076721b8028e", I think. If you'd like me to test with a particular revision, just say so and I can do that.

Then it's either a fault in poppler-glib bindings or evince, poppler-qt4 correctly returns false as we don't know how to modify encrypted files at the moment. So it seems either poppler-glib bindings or evince don't cope correctly with poppler core returning false on save.

Carlos can you have a look?

(In reply to comment #3)
> Then it's either a fault in poppler-glib bindings or evince, poppler-qt4
> correctly returns false as we don't know how to modify encrypted files at the
> moment. So it seems either poppler-glib bindings or evince don't cope correctly
> with poppler core returning false on save.

you are right. It has to be fixed in both poppler-glib and evince then.

> Carlos can you have a look?
>

Yes.

Well, we already check the retval, but we don't properly fill the GError, and that's why evince doesn't notice an error ocurred. The problem is that there's no way to know why saveAs() failed, it might be because the document is encrypted or because the file couldn't be open for writing. We could probably use PDFDoc::errCode, what do you think?

Created an attachment (id=23177)
[PATCH] Set PDFDoc::errCode when saveAs() fails

 poppler/PDFDoc.cc | 3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

I'm not sure i like this errCode meaning change, after all PDFDoc.h says

  // Was PDF document successfully opened?
  GBool isOk() { return ok; }

  // Get the error code (if isOk() returns false).
  int getErrorCode() { return errCode; }

what about changing PDFDoc::saveAs to return an int?

I tested the following setup (all checkouts were the current version as of about yesterday):

cairo eb2a73ba6d290497cabb0f917c0375eea919178e (1.9.1 series)
poppler 26a8217160c1eaeeadb92023b27e68f402e38dd0 + Carlos's patch
evince r3496

Other libraries are whatever's in the current Ubuntu 8.10 (Intrepid) distribution.

Loading, editing a form field in, then saving the affected PDF still results in a zero-byte file, with no errors reported on the command line or via the GUI.

Oddly enough, this version of evince is supposed to deal with this situation from that end; see GNOME bug 566791, which was about the same problem, and this revision, which was included in the tested version:

http://svn.gnome.org/viewvc/evince?view=revision&revision=3493

Is the above setup working for anyone? I may be testing it wrong, but I don't think so; I'm quite sure that my testing copy of evince is linked to my testing copy of the poppler libs, and so on.

Is there any further debugging or tracing that I could do that might be of some help?

(In reply to comment #8)
> I tested the following setup (all checkouts were the current version as of
> about yesterday):
>
> cairo eb2a73ba6d290497cabb0f917c0375eea919178e (1.9.1 series)
> poppler 26a8217160c1eaeeadb92023b27e68f402e38dd0 + Carlos's patch
> evince r3496
>
> Other libraries are whatever's in the current Ubuntu 8.10 (Intrepid)
> distribution.
>
> Loading, editing a form field in, then saving the affected PDF still results in
> a zero-byte file, with no errors reported on the command line or via the GUI.
>

hmm, did you run make install after updating evince?

>hmm, did you run make install after updating evince?

Yes; I made a testing directory and built everything with the prefix pointing to that directory, then installed the packages. (I had to install cairo to build poppler, since poppler needs a newer version of cairo than Intrepid ships, and I had to install poppler to build evince.) I verified that the new copy of evince was using the libs I'd built before it:

$ ldd /tmp/evince-test/inst/bin/evince|egrep '(cairo|poppler)'
 libpoppler-glib.so.4 => /tmp/evince-test/inst/lib/libpoppler-glib.so.4 (0xb7a13000)
 libpoppler.so.4 => /tmp/evince-test/inst/lib/libpoppler.so.4 (0xb7856000)
 libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7614000)
 libcairo.so.2 => /tmp/evince-test/inst/lib/libcairo.so.2 (0xb74e6000)

And I executed it by explicitly invoking it.

$ dpkg -l evince
ii evince 2.24.1-0ubuntu1 Document (postscript, pdf) viewer
$ /tmp/evince-test/inst/bin/evince --version
GNOME Document Viewer 2.25.91

The "Help->About" dialog also reports the newer version. Is this system working on your system? Perhaps there's another library I'd need to build to get it working, though I'm skeptical of that.

Created an attachment (id=23389)
[PATCH] Return an error code instead of a GBool when saving

 poppler/PDFDoc.cc | 22 +++++++++++-----------
 poppler/PDFDoc.h | 8 ++++----
 2 files changed, 15 insertions(+), 15 deletions(-)

Note that it requires changes in the frontends too, since now we are returning errNone (which is 0) when successing .

I like this better, please commit and warn the mailing list about the change so people can update the frontends.

Fixed in git master. Thanks.

Excellent! I pulled the current version of poppler master (de3131ae38fc9442b198d4d7b0c57c6939ad66ce), rebuilt, and now Evince prints pops up an error bar ("The file could not be saved as “file:///tmp/evince-test/FormularioTransferencia-change.pdf”. / Document is encrypted") rather than saving a zero-byte file.

*** Bug 21071 has been marked as a duplicate of this bug. ***

I'm having similar zero length files on what would seem to be every save as copy.

This even happens on opening a local file that was previously saved by evince.

No error in gui or cli when this happens.

Seems like the error trapping is no rigorous enough.