GNOME Bugzilla – Bug 564153
Form contents are invisible when cursor leaves field, but data is still saved in form.
Last modified: 2013-06-11 10:32:24 UTC
Please describe the problem: In certain PDF documents, form data can be entered into fields, and will reappear when the field is selected again, but is not displayed. It's as though the form data is invisible, though it appears again when the form is re-selected. Steps to reproduce: 1. Open f1040.pdf (will be attached). 2. Select the 'Your first name and initial' field. 3. Type in some data. 4. De-select the field. Actual results: The form data vanishes, though it reappears if the field is re-selected. Expected results: The form data should appear in blue in the field. Does this happen every time? Yes; this is repeatable. Other information: The form data can be saved from evince and seen (when the field is selected) in either evince or acroread; the problem seems to be solely with its display. The contents of the fields are visible when filled in with acroread. This issue is present only in specific PDF forms, such as the version of f1040.pdf currently on the IRS's website (last modified November 14, 2008). Other PDFs do not trigger the issue. The console sometimes outputs the string "Error: Unknown font in field's DA string" when I de-select a text form field; this appears to be related, but I don't know what the error message means. This bug has been tested with a version built using Cairo 1.8.4, Evince SVN r3295, and Poppler c9a755f9fd14511f43a2ca7fcda36bdd64bb1d87 (pulled from git today). Please let me know if this is a poppler bug; I can file it there if necessary. This bug was originally filed at Ubuntu's bugtracker a few months ago; I reopened it when I discovered that I could reproduce the issue. https://bugs.launchpad.net/ubuntu/+source/evince/+bug/265033
Created attachment 124437 [details] PDF file triggering the bug. This file was downloaded from http://www.irs.gov/pub/irs-pdf/f1040.pdf, but as that file may be changed or updated, and this bug seems difficult to trigger, I'm attaching it here.
Please note that this is distinct from bug 563620; in that bug, form data is not persisted. In this bug, form data is persisted, but does not display properly.
Created attachment 124443 [details] PDF file with invisible text. This PDF file is the same as the f1040.pdf attached previously, but with the fields filled in by Evince. You can see the content of the fields (e.g., "Your first name and initial") when the field is being edited, but the result vanishes when the field is de-selected. This can be seen in Evince or in Acroread.
I think this is a Poppler bug. If you look at the console output, when you release focus from a text input field, the following error message is printed: Error: Unknown font in field's DA string This string occurs twice in poppler's "poppler/Annot.cc". Debugging further (printf-style), it appears that the PDF token /HeBo is not being found in the font list (which, based on some internet searching, I think means "Helvetica Bold" - makes sense for a US government document). Even after adding a Helvetica.ttf into ~/.fonts, reloading the fontconfig cache, making sure it is listed via `fc-list` ("Helvetica:style=Bold"), the error persists. FWIW, this was tested with cairo 1.8.6, poppler 0.10.3 / git revision 0ed3fd52, and evince 2.24.2 on Gentoo.
I can confirm that I see this book using evince 2.24.1 backported to hardy.
I can confirm this with # rpm -q poppler evince poppler-0.14.5-1.fc14.i686 evince-2.32.0-3.fc14.i686
(In reply to comment #0) > Other information: > The form data can be saved from evince and seen (when the field is selected) > in either evince or acroread; the problem seems to be solely with its > display. Not just display. When the form is printed, the entered text is missing too.
In my case the fonts used by the PDF with non-working form input text are: -------------- $ pdffonts Viisumianomus.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- Arial-BoldMT TrueType no no no 256 0 ArialMT TrueType no no no 253 0 ArialNarrow TrueType no no no 260 0 Arial-ItalicMT TrueType no no no 269 0 ABCDEE+Arial,Bold CID TrueType yes yes yes 9 0 ABCDEE+Arial TrueType yes yes no 14 0 ABCDEE+Arial,Bold TrueType yes yes no 7 0 ABCDEE+Arial,Bold TrueType yes yes no 5 0 ABCDEE+Times New Roman TrueType yes yes no 16 0 MYXTPU+Arial,Bold TrueType yes yes no 159 0 -------------- According to "man pdffonts", the name column contains: the font name, exactly as given in the PDF file (potentially including a subset prefix) According to quick googling: http://forums.adobe.com/thread/285559 http://tex.stackexchange.com/questions/23104/using-and-interpreting-pdffonts The random prefixes ("MYXTPU+" and "ABCDEE+") are used for embedded font subsets. Could embedded font subset naming or their support in Evince/poppler be related to the issue? Similar things are listed for document discussed in the Ubuntu bug.
This problem happens because the Default Appeareance stream (the stream that specifies how a field must be rendered) of the Fields in the Form of the IRS 2008 use a font that is not declared in the PDF file, but instead is one of the standard 14 pdf fonts. The PDF spec is not quite clear about whether the testcase is a valid example or not (newer versions of the IRS form don't have this problem), but nevertheless I posted a patch to poppler to see if we can gracefully handle these kind of "broken" forms.
José, Do you have a link with the patch you posted?
Poppler bug -> NOTGNOME.