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

Bug #265033 reported by Daniel Karlsson
120
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Evince
Unknown
Medium
One Hundred Papercuts
Invalid
Undecided
Unassigned
Poppler
Unknown
Medium
poppler (Ubuntu)
Triaged
Medium
Ubuntu Desktop Bugs
Declined for Jaunty by Sebastien Bacher

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

Revision history for this message
Pedro Villavicencio (pedro) wrote :

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.

Changed in evince:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Daniel Karlsson (daniel-e-karlsson) wrote :

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

/Daniel

Changed in evince:
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in evince:
status: New → Incomplete
Revision history for this message
Daniel Karlsson (daniel-e-karlsson) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

closing the bug since that works correctly now

Changed in evince:
status: Incomplete → Fix Released
Revision history for this message
Adam Buchbinder (adam-buchbinder) wrote :

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.

Changed in evince:
status: Fix Released → New
Revision history for this message
Adam Buchbinder (adam-buchbinder) wrote :

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.

Revision history for this message
Adam Buchbinder (adam-buchbinder) wrote :

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.)

Revision history for this message
Adam Buchbinder (adam-buchbinder) wrote :
Changed in evince:
status: New → Triaged
Changed in evince:
status: Unknown → New
Revision history for this message
In , Bradley M. Kuhn (bkuhn-ebb) wrote :

This bug has been reported in evince at http://bugzilla.gnome.org/show_bug.cgi?id=564153 and https://bugs.launchpad.net/ubuntu/+source/evince/+bug/265033 but it is believed this is a poppler bug.

Steps to Produce:
1. Use some of the forms from irs.gov, such as the 2008 f1040.pdf that is attached.
2. Enter data in any field.
3. Press return.

Actual Results:
Data is there until you press return, then it disappears. If you click on field again, you see the data again until you hit return.

Expected Results:
Data should stay even when field isn't selected.

It's believed this is a poppler bug and not evince, because the following error appears on stdout just after return is hit:
   Error: Unknown font in field's DA string

which appears to come from poppler/poppler/Annot.cc

Revision history for this message
In , Bradley M. Kuhn (bkuhn-ebb) wrote :

I have, BTW, confirmed the bug with poppler version 0.10.3 and evince 2.24.1

Revision history for this message
In , Bradley M. Kuhn (bkuhn-ebb) wrote :

Created an attachment (id=22693)
IRS 2008 Form 1040 from http://www.irs.gov/pub/irs-pdf/f1040.pdf

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

Actually we are not doing anything bad, the forms define HeBo font as the font that should be used for rendering them and no HeBo font is defined on the document.

Agreed that we can add a workaround for broken documents like this, will do when i have some time, that is probably never. If anyone wants to do it, feel free to write a note here you are starting to work on it so we don't duplicate work.

Revision history for this message
Bradley M. Kuhn (bkuhn-ebb) wrote :

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.

Revision history for this message
Bradley M. Kuhn (bkuhn-ebb) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in poppler:
status: Unknown → Confirmed
Revision history for this message
dgandhi (dgandhi) wrote :

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.

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

raising importance to medium

Changed in poppler:
importance: Low → Medium
Revision history for this message
In , Albert Astals Cid (aacid) wrote :

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

Revision history for this message
In , Adam Buchbinder (adam-buchbinder) wrote :

I've sent an email to the support folks at Amgraf, the company responsible for the software that generates the IRS's PDFs. (I'd called on the phone and (poorly) attempted to describe the situation to a rep, who suggested that I email the support department.)

I've also found a couple of references on the short font names for use in 'DA' fields in forms. iText, for instance, includes the list.

http://itext.svn.sourceforge.net/viewvc/itext/trunk/src/core/com/lowagie/text/pdf/AcroFields.java?revision=3771&view=markup#l_2320

See the Scribus source, here, in PDFlib::PDF_Annotation().

http://scribus.info/svn/Scribus/branches/start/Scribus/scribus/libpdf/pdflib.cpp

Here's the original bug report for Scribus; it seems that it's just an extraordinarily common, though undocumented, extension; maybe seeing how another PDF-using system dealt with the problem will be helpful.

http://bugs.scribus.net/view.php?id=4620

The first table in this tutorial (p. 10) from 1999 has the list in it, so it goes back at least that far.

http://www.math.uakron.edu/~dpstory/tutorial/pdfmarks/forms.pdf

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Still present in Lucid.

Revision history for this message
wpshooter (joverstreet1) wrote :

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.

Revision history for this message
wpshooter (joverstreet1) wrote :

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.

Revision history for this message
In , Sergio Zanchetta (primes2h) wrote :

Created an attachment (id=33657)
A file to test

Here is another file suffering of this bug.
Does it have the same font problem as the other one?

It doesn't seem.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Another file suffering of this bug to test.

Revision history for this message
dentonlt (denton) wrote :

[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

Revision history for this message
Vish (vish) wrote :

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.

Changed in hundredpapercuts:
status: New → Incomplete
Revision history for this message
b49P23TIvg (b49p23tivg) wrote :

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.

Changed in poppler:
importance: Unknown → Medium
Changed in evince:
importance: Unknown → Medium
Revision history for this message
Yfrwlf (yfrwlf) wrote :

(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.

Revision history for this message
Yfrwlf (yfrwlf) wrote :

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

Changed in poppler:
importance: Medium → Unknown
Changed in poppler:
importance: Unknown → Medium
Changed in hundredpapercuts:
status: Incomplete → Invalid
Revision history for this message
Alan Grow (alangrow) wrote :

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

Revision history for this message
Marcus Haslam (marcus-haslam) wrote : Re: [Bug 265033] Re: Form contents are invisible when cursor leaves field, but data is still saved in form.

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

Revision history for this message
Franck (alci) wrote :

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...

Changed in evince:
status: New → Unknown
Revision history for this message
casrep87 (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?

Revision history for this message
wpshooter (joverstreet1) wrote :

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?
>

Revision history for this message
In , Kip Warner (kip) wrote :

I can confirm this bug with IRS Form 2008 using Evince 3.16.1.

Revision history for this message
Michael Aquilina (michaelaquilina) 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?

Revision history for this message
wpshooter (joverstreet1) wrote : Re: [Bug 265033] Re: Form contents are invisible when cursor leaves field, but data is still saved in form.

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?
>

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/441.

Changed in poppler:
status: Confirmed → Unknown
Revision history for this message
Björn Schließmann (b-schliessmann) wrote :

Still present with 3.36.7-0ubuntu1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.