Form contents are invisible when cursor leaves field, but data is still saved in form.

Thanks for the report, please attach an example to the report, there's a few files on that site and don't know with which of them are you having issues, thanks.

E.g. this one
http://www.quask.com/samples/pdfforms/pcpurchase.pdf
but all forms I've tried have the same problem

/Daniel

not confirming using the current version on the example, do you still have the issue?

Tried again today, and the issue is gone using version 2.23.92-0ubuntu1.

closing the bug since that works correctly now

I can replicate this problem with this year's IRS Form 1040. It doesn't affect other forms on that site randomly selected, like Form 8038-T or Form 1040-EZ.

I see "Error: Unknown font in field's DA string" on console output, but I don't know how related that is.

I'm running evince 2.24.1-0ubuntu1 with libpoppler3 0.8.7-1.

Adding: the console error appears to be related; I see it when I leave a field. It repeats a larger number of times each time I see it. I'm attaching a copy of IRS form 1040, filled in with evince. You can see the data in the fields ("Your first name and initial", for instance) if you select the fields, but otherwise, the data is invisible.

Filling the form in with acroread 8.1.3 works properly. The data is indeed being saved; if I edit a field in acroread, it becomes visible, both in acroread and in evince.

This is still present in an upstream version I built using Cairo 1.8.4, Evince SVN r3295, and Poppler c9a755f9fd14511f43a2ca7fcda36bdd64bb1d87 (pulled from git today). Sending it upstream to Evince (though they may bounce it to Poppler, if it's a Poppler issue.)

I have confirmed this bug with various irs.gov forms, including the f1040.pdf that Adam attached in the last comment. I also confirmed the bug in later versions by backporting 2.24.1-0ubuntu1 to hardy.

Adam commented on the evince upstream ticket at
http://bugzilla.gnome.org/show_bug.cgi?id=564153 that it is likely a poppler bug. I think he's right and I've opened a poppler bug on this: https://bugs.freedesktop.org/show_bug.cgi?id=20009

don't accepting the jaunty nomination that's not a new issue nor a blocker for jaunty

The current problem seems to be in the files. The f1040.pdf is bad, as it references the font HeBo, when it has no such font defined. I used this shell command to fix the file:

cat f1040.pdf | sed -e 's%/HeBo%/Helv%g' > f1040-fixed.pdf

The folks commenting on the poppler bug report seem to agree that poppler catches the error, but no default font override exists, nor does that appear to be trivial, or even desirable.

raising importance to medium

Still present in Lucid.

I am fairly sure that this bug has been present & reported for about 2 to 3 years now. Seems to me it is about time this was fixed.

Also, IMO, the importance of this needs to be HIGH not medium !!! Can't even fill out a simple IRS form on-line without getting an error.

Thanks.

I have come to the conclusion that these bugs/problems related to NOT being able to properly fill-in information on forms on the IRS website is NOT related to bugs/problems in either the Evince, Acroread, or full version of Adobe Acrobat Reader programs but rather a bug/problem in the FIREFOX browser.

I say the above because if you save the forms from either the IRS or VDOT website to your hard drive and then close the Firefox browser and then just open these save forms from your hard drive and then try to fill them in, the functioning of filling in the information on the forms, the movement of the cursor from field to field on the forms, then subsequent saving of both the form and the filled in information of the forms work JUST GREAT. Therefore, this sort of indicates to me that the problem in with FIREFOX browser, since at this point it has been taken out of the equation.

I don't know if fixing this problem with Firefox is the responsibility of whoever monitors this bug reporting tool but if not it would sure be swell if someone could report this problem to whoever is responsible for the code of the Firefox browser so this problem could finally be fixed.

Thanks.

Another file suffering of this bug to test.

[bump]

Same problem - form field contents disappear when the cursor leaves the field. In my case, contents are completely lost.

When entering a form field, Evince gives a "bad form bounding box" error at the console.

I am using a bare-bones Tiny Core 2.9 (debian-like) installation + plain jane Evince + updated poppler/gconf/etc.

I have tried a few PDF forms created using Adobe - all forms work fine on Adobe Win, Foxit Win. Evince is the only form editor I've seen on Linux, or I would try the form elsewhere. (I'm searching!) I'll re-test on Ubuntu, but expect the same.

I'll join the bug-digging team here, as I really need this to work out.

DLT

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- This is a bug and does not seem to be trivially fixable.
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Incomplete" only in the papercuts project.

I'm satisfied to cite the IRS for choosing an unusual font in 2008. I'm pretty sure the stream editor command a few comments earlier will fix the problem. This was my first idea, and reading here was easier than interpreting "strings f1040--2008.pdf". Thank you.

(This is not a problem with Firefox btw.)

I have a PDF file that I saved (also from a government website). After opening and editing the fields in this PDF file, the font format disappears after clicking away from the field due to, apparently, Evince not being able to recognise the desired font type that the PDF wants for that field, and so not displaying anything at all as a result.

However, you don't need to do any kind of font type conversion or whatnot to fix this issue. After simply saving the PDF file again *using Evince* (using "Save a Copy..."), it will then change the font type of the fields to some other type it actually can actually display,. Then, if you open the new copy, and edit the fields, it will then display the entered text in the fields.

If you look at the properties of both PDF files using Evince, in the font tab it lists three extra named fonts in the new saved copy along with a bunch of "no name" fonts, while the original PDF that has invisible fields only lists the "no name" fonts.

I think dgandhi's comment above that having Evince default to some font type if the font type a field is calling for isn't recognised being undesirable is a huge mistake. It's MUCH more desirable to have a slightly incorrect font type appear in a field than having a user experience invisible fields, it not only being extremely confusing but also making it impossible to print the PDF as no entered form data would show up. Also, another useful feature, semi-solution, and also to correct dgandhi's concern would be if Evince had a font selector. This way, even if the default font was too different looking from what the PDF field had originally been calling for, the user could select a font type that was more similar.

Regardless though, making Evince choose a default font type should be the immediate solution to this bug which I agree is a fairly severe bug to have, even if it only effects certain PDF documents. Here in the U.S. at least, unknown font types coming from government PDF files seems to be fairly common.

Sorry, in the opening paragraph I meant the entered characters disappear after clicking away (or hitting enter). Curse not being able to edit. ^^

It's 2011 and the IRS is still using a non-standard font in the 2010 tax forms -> this bug still affects people.

I'm out of the office until 1st August.

On 18 Apr 2011, at 04:23, Alan Grow <email address hidden> wrote:

> It's 2011 and the IRS is still using a non-standard font in the 2010
> tax
> forms -> this bug still affects people.
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/265033
>
> Title:
>  Form contents are invisible when cursor leaves field, but data is
>  still saved in form.
>
> Status in Evince document viewer:
>  New
> Status in One Hundred Paper Cuts:
>  Invalid
> Status in Poppler:
>  Confirmed
> Status in “poppler” package in Ubuntu:
>  Triaged
>
> Bug description:
>  Binary package hint: evince
>
>  When filling in forms, data becomes invisible after pressing enter.
> Data is present, just not visible. Data becomes visible when
> editing. Problems exist with forms on the gnome.org evince web site.
>  http://live.gnome.org/Evince/Forms
>  Description: Ubuntu intrepid (development branch)
>  Release: 8.10
>  evince:
>    Installed: 2.23.6-0ubuntu1
>    Candidate: 2.23.6-0ubuntu1
>    Version table:
>   *** 2.23.6-0ubuntu1 0
>          500 http://se.archive.ubuntu.com intrepid/main Packages
>          100 /var/lib/dpkg/status
>  BTW, "Report a problem did not work"
>  Tried with and without compiz with identical results

Bug is still present in Ubuntu 12.10 / evince 3.6.0-0ubuntu2.

Opening a document with forms, data filled in forms just won't show. It won't print either. Going in the form field (once you know there is one !) shows the data, until you leave the field.

Works just fine in Okular (okular ask if you want to show/hide the form).

Makes evince quite unusable, as for every pdf you open, you are uncertain if the complete document is shown...

Any status on this recently? I'm still having this problem.

http://www.eac.gov/assets/1/Documents/Federal%20Voter%20Registration_6-25-14_ENG.pdf

Has a workaround been discovered?

I no longer have this problem.

Now, when I type the info in the form I CAN see it and when I advance to
the next field on the form the info in the previously completed field is
still visible and can be save and/or printed as a completed form.

Thanks.

On Mon, 2015-01-05 at 06:04 +0000, casrep87 wrote:
> Any status on this recently? I'm still having this problem.
>
> http://www.eac.gov/assets/1/Documents/Federal%20Voter%20Registration_6-25-14_ENG.pdf
>
> Has a workaround been discovered?
>

This also affects me with evince 3.16.1. I'm pretty surprised this is still an issue after 7 years. Is there a specific type of form it affects?

Michael:

 To the best of my knowledge I am no longer having this problem.

 However, that may be due to the fact that I no longer use Ubuntu
operating system but switched to exclusive use of Linux Mint (version
17) about 2 years ago.

 Thanks.

On Mon, 2015-12-14 at 23:25 +0000, KillaW0lf04 wrote:
> This also affects me with evince 3.16.1. I'm pretty surprised this is
> still an issue after 7 years. Is there a specific type of form it
> affects?
>

Still present with 3.36.7-0ubuntu1.