After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564153 - Form contents are invisible when cursor leaves field, but data is still saved in form.
Form contents are invisible when cursor leaves field, but data is still saved...
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: PDF
git master
Other All
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on: 693645
Blocks:
 
 
Reported: 2008-12-11 17:38 UTC by Adam Buchbinder
Modified: 2013-06-11 10:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
PDF file triggering the bug. (346.15 KB, application/pdf)
2008-12-11 17:47 UTC, Adam Buchbinder
Details
PDF file with invisible text. (353.11 KB, application/pdf)
2008-12-11 18:24 UTC, Adam Buchbinder
Details

Description Adam Buchbinder 2008-12-11 17:38:59 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
Comment 1 Adam Buchbinder 2008-12-11 17:47:37 UTC
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.
Comment 2 Adam Buchbinder 2008-12-11 18:21:32 UTC
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.
Comment 3 Adam Buchbinder 2008-12-11 18:24:08 UTC
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.
Comment 4 Mark Lee 2009-02-03 20:34:59 UTC
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.
Comment 5 Bradley M. Kuhn 2009-02-08 15:12:11 UTC
I can confirm that I see this book using evince 2.24.1 backported to hardy.
Comment 6 Felix Möller 2011-02-25 00:01:59 UTC
I can confirm this with

# rpm -q poppler evince
poppler-0.14.5-1.fc14.i686
evince-2.32.0-3.fc14.i686
Comment 7 Eero Tamminen 2012-07-04 09:21:55 UTC
(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.
Comment 8 Eero Tamminen 2012-07-04 09:41:09 UTC
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.
Comment 9 José Aliste 2013-02-18 12:43:13 UTC
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.
Comment 10 Germán Poo-Caamaño 2013-02-18 19:25:52 UTC
José,

Do you have a link with the patch you posted?
Comment 11 Christian Persch 2013-06-11 10:32:24 UTC
Poppler bug -> NOTGNOME.