Bug forwarded from Evince: http://bugzilla.gnome.org/show_bug.cgi?id=565152 "Please describe the problem: For checkboxes created in OpenOffice 3.0, and I believe Scribus as well, the exported PDF forms do not work. The checkboxes are blank and no checks appear when clicked. These same PDFs work in acroread and even in GV. Steps to reproduce: 1. Open the attached PDF (bugreport.pdf) 2. Click on one of the check marks 3. Scratch your head because no tick appeared Actual results: Nothing Expected results: A check should appear in the box Does this happen every time? Yes Other information: Example files for this bug can be found at the follwing website: bugreport.odt - OpenOffice.org Writer doc that was used to generate the PDF bugreport.pdf - Editable form that does not work in Evince but does in acroread bugreport-filled.pdf - Form filled using iTextSharp that works in both (flattened)" A test case is attached to the original bug report. It seems to be a problem with fonts, that's what I see in stdout when trying to select any of the checkboxes with evince: Error: Unknown font in field's DA string
I think that is probably the same bug as one I just reported at http://bugs.kde.org/show_bug.cgi?id=179426, although there's a possibility that it's different. I don't believe that the form in my case was generated by OO.o (it's a form from the UK Inland Revenue). Here is my bug report from kde.org: ---- I received a PDF form from an attorney. The form contains checkboxes, and okular represents different checkboxes as being checked than Acrobat Reader does. Acrobat Reader's interpretation is correct. In other words, some checkboxes are rendered by okular as being checked when in fact they are not checked, and vice versa. I don't think that I really need to point out that this bug can have terrible consequences if the form being rendered is from an attorney or accountant. I have tried to extract a single page that does not contain personal information (so I could attach it here) but have not been able to do so. ---- Assuming that this is indeed the same bug as originally reported, the potential for disaster suggests that this bug be addressed as quite a high priority. (I was on the phone walking through the form when I realised to my horror that I was seeing different checkboxes checked than was the person at the other end of the phone.)
I'm 99% sure it's not the same bug. It may be critical for you, and i even might agree, without the document the probabiliy of it getting fixed is VERY small.
Bug should be fixed in poppler 0.10.3 due for release in January 9th
Hi everybody, On my side I can confirm that the check-box problem disappeared by using 0.10.3, so thanks for that first! :-) But I still get this console error message when clicking on a radio-button: Error: Missing 'Tf' operator in field's DA string And nothing appears on the form (looks like you didn't clicked), the same as it was for check-boxes. So it's very similar to this bug but I'm not absolutely sure if it's related though… If not, let me know and I'll open a new bug for that (a quick bug search gave nothing at this time).
Well, the check-box tick does appear *but* the checked status doesn't get saved when saving a copy of the form from within Evince… Is it still a poppler bug or could it be some Evince bug? I feel I have to reopen this bug conforming to its subject, sorry!
Right now it's designed this way. You can print the filled form, but copy will be blank. It's true for all input controls.
(In reply to comment #6) > Right now it's designed this way. You can print the filled form, but copy will > be blank. It's true for all input controls. In fact recent versions of Evince (from 2.24 for sure, may be even 2.23) allows you to save a copy of your form including filled data. It works with text-fields and drop-list (I've tested them) but not with check-boxes and radio-buttons.
Closing the bug, saving works, i've saved the pdf in okular and opened in Acrobat Reader and the checked option was there. If evince does not let you do that, file a bug against evince, though maybe is a missing feature in poppler-glib binding, still it is a different bug. Also if you have a document with radio buttons that fails, open a new bug, but do not hijack this one.
(In reply to comment #8) > Closing the bug, saving works, i've saved the pdf in okular and opened in > Acrobat Reader and the checked option was there. If evince does not let you > do that, file a bug against evince, though maybe is a missing feature in > poppler-glib binding, still it is a different bug. > > Also if you have a document with radio buttons that fails, open a new bug, but > do not hijack this one. Understood. BTW, thanks for the hint about okular.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.