PDF Fields Appear Invisible with PDF Clown

Question

I use the Java version of PDF Clown to fill out the fields of PDF Acroforms. This works great and I'm able to programmatically fill out forms and save them without any issues.

However, some PDF viewers render some of the text invisible in the fields I'm filling out, unless you click on them in which case they become visible. This forum post explains that this can happen in form-fillable PDFs in general and that it can be fixed by setting the background color of the PDF field to "None", even if the GUI already says that the background color is "None." This has worked for others and I'd like to try it for myself.

Unfortunately, I"m stuck on how to actually do this in PDFClown. There isn't a direct method like field.setBackgroundColor(null) for the Field class and I'm not able to figure out a way to do it by using one of the other accessor methods, like getDefaultAppearanceState().

Is there anyone who knows how to do this in PDF Clown?

EDIT: A sample PDF with this issue can be found here. Everything in this PDF was filled in with PDF Clown. Note in particular that the two fields in the upper left (labeled with "Name") are invisible until clicked on. The five fields in the right are also invisible until clicked on, except for the "Charisma" field, which was previously invisible, but then I manually typed in the value and then it was made visible. Everything else was put in by PDF Clown, but unlike the other fields was made visible.

EDIT 2: It has since been discovered that this only happens when you overwrite values in an existing form-fillable character sheet. An original can be downloaded here.

BTW, this may happen if your filled out PDF neither has appearance streams for the filled-out fields (counting on the PDF viewer to create some appropriate appearance) nor the **NeedAppearances** flag set (which, if set, instructs the PDF viewer to create appearance streams); something like that has been the topic of [Editable .pdf fields disappear (but visible on field focus) after save with evince](http://stackoverflow.com/questions/13390236/editable-pdf-fields-disappear-but-visible-on-field-focus-after-save-with-evin/13452217). Please check your PDF for this or provide a sample PDF. — mkl, Apr 22 '13 at 12:04
@mkl an example PDF with this behavior is now in the question. There is an enum for flags that can be set on a field (http://bit.ly/109LHFi), but I don't see one called NeedAppearances. — Thunderforge, Apr 22 '13 at 21:10

mkl · Answer 1 · 2013-04-23T10:26:21.087

As a first analysis:

Nearly as suspected in my original comment, the field "Name Line 1" contains the value (field dictionary V) "Doc Lightning" but a normal appearance stream (field dictionary AP -> appearances dictionary, key N) which displays no text.

Furthermore the interactive form dictionary entry NeedAppearances is not set to true; thus, the PDF viewer is made believe that the appearance streams are up-to-date. Only when you click into the field and, therefore, signal that you want to edit, the PDF viewer generates a new appearance of the stream, an appearance of its own making which it understands completely for the task of editing.

If you filled in that form field and no other tool changed your results afterwards, therefore, something is wrong either in your code or in PDF Clown. Please provide some self-contained sample code and not-yet-filled-in document to reproduce the issue.

EDIT:

I just applied the current (trunk) PDF Clown AcroFormFillingSample.java sample to the not-yet-filled-in Character Sheet (i.e. the revision consisting of the initial 1458834 bytes of your file), and the result is ok, all field contents are visible even without clicking into them. Thus there is something special in your source... (or do you use an older version?)

In detail:

Page 1 of the character sheet of Doc Lightning references the annotation in object 162:

/MK      <<>>
/F       4
/Type    /Annot
/Subtype /Widget
/Rect    [37.0108, 617.055, 156.923, 631.717]
/FT      /Tx
/DA      /Helv 12 Tf 0 g
/T       (Name Line 1)
/V       (Doc Lightning)
/P       47 0 R
/AP      537 0 R

Thus, the value of the field indeed is "Doc Lightning".

On the other hand, the appearances dictionary in object 537 references the normal appearance stream:

/N       538 0 R

And the stream in object 538 only contains:

/Tx BMC
q
1 0 0 1 2 -7.331 cm
/Helv 12 Tf
Q
EMC

So the normal appearance stream positions in the field (setting the current transformation matrix accordingly) and selects a font (Helvetica, properly defined in the ressources, BTW), and then prints... nothing!

The interactive form dictionary (object 144) does not contain a NeedAppearances entry at all. According to the PDF specification ISO 32000-1:2008, Table 218, this entry is

A flag specifying whether to construct appearance streams and appearance dictionaries for all widget annotations in the document (see 12.7.3.3, “Variable Text”). Default value: false.

Thus, the PDF viewer acts just like expected when not showing the value "Doc Lightning" of "Name Line 1" but instead the empty appearance stream.

Thank you for your very detailed analysis! I believe what happened was that I put in empty strings for those "empty" fields when I was setting up the PDF, then later overwrote those empty values with actual text. I obtained a new unfilled PDF and had no further issues. Of course, this leads to the question of how to prevent the invisible text when I fill it out once, then overwrite it again. — Thunderforge, Apr 23 '13 at 19:38
Hhmmm, if filling the field twice has such unwanted effects, you might want to report to PDF clown development... — mkl, Apr 23 '13 at 21:07
True, it could be a bug in PDFClown. Basically, I found out from your answer that overwriting fields doesn't work, you have to do it once. — Thunderforge, Apr 23 '13 at 21:17
Well, I think it is a bug or at least something that requires to be documented. — mkl, Apr 24 '13 at 07:43
After revisiting this issue, I found out it wasn't a bug in PDF Clown. Buried deep inside the sample files was a method with three lines of code that I didn't include in my own source, which seems to create an appearance for reading. I've switched the accepted answer to that one so that others can find the answer more easily, but I truly want to thank you very much for your work in helping me solve this problem! — Thunderforge, Jul 31 '13 at 06:58

score 0 · Accepted Answer · answered Jul 31 '13 at 06:54

After revisiting this issue, and carefully looking at the source code, I realized that the Sample.java class of PDFClown's samples had an applyDocumentSettings() method that contained three lines of code missing from my source:

//Previously we instantiated "document" from org.pdfclown.files.File.getDocument()
ViewerPreferences view = new ViewerPreferences(document); // Instantiates viewer preferences inside the document context.
document.setViewerPreferences(view); // Assigns the viewer preferences object to the viewer preferences function.
view.setDisplayDocTitle(true);

I'm not sure that the last line is actually necessary, but I went ahead and kept it in for good measure.

The user mkl wrote in his answer that "the PDF viewer generates a new appearance of the stream, an appearance of its own making which it understands completely for the task of editing." It seems that what the lines of code do above is generate an appearance that is understood to be for reading (and maybe editing?).

Have you compared the outputs with and without that addition? I ask because the **ViewerPreferences** a priori don't have anything to do with form field appearances. — mkl, Jul 31 '13 at 07:21

PDF Fields Appear Invisible with PDF Clown

2 Answers2