Acrobat Reader and Pro: drop-down form elements are not processed correctly

[Guest]

We have users/clients who use non Adobe products to view pdfs and fill out forms.We also use a server-software which

After Firefox discontinued support for the Acrobat plugin, we installed a server-software which autofills forms, instead of supplying an fdf.

Everything works well with non Adobe products, however if somebody opens the pdf with filled forms in Acrobat, all filled drop-downs seem to be blank.

While we urge our users to use Adobe Acrobat, our clients tend to switch to other software. We fear that our company will be forced to give up adobe reader, while you are our preference for years.

Is there any fix to this issue? Any script or program to "fix" the pdfs (in a way that they work in any software)? Or do you plan to make an update?

All other form fields seem to work without any issues.

[try67]

It sounds like a bug with the software you're using to fill in the forms... Unless you can share a sample file there's nothing much else we can do. Also, you should report this issue to the developers of that software.

[Test Screen Name]

How could Adobe fix bugs in other people's software? Many PDF readers, such as those on mobile devices, don't even try. You identify a real problem. Unfortunately I believe PDF forms are killed by PDF's success, we are just seeing the dying days before everyone transitions to HTML forms.

[Guest]

We are using  http://www.fpdf.org/en/script/script93.php  to pupulate the forms, so far Acrobat and Firefox Built-In plugin have issues.
Unfortunatelly I cannot upload the pdf file, since we cannot anonymize it easely.... And if I anonymize it using our editor, the fields become viewable by Acrobat and Firefox.

[Test Screen Name]

If your server component makes forms which don't display correctly in Acrobat, it is wrong. A common error is neither creating appearance streams nor setting NeedAppearances. This is something to take up with the author. If it is wrong in OTHER software, not much can be done.

[Guest]

We are using Adobe Acrobat forms, we are just populating the forms on the server with user data.

So far Adobe Acrobat (Reader), and original pdf viewers in Microsoft Edge and Firefox (both cannot be used to fill forms) are affected.

"A common error is neither creating appearance streams nor setting NeedAppearances." - any additional sources on this issue?

[Test Screen Name]

If you have a library specifically designed to fill forms, please pass this tip along to whoever supports it. If you use a general PDF library, look into how to set NeedAppearances yourself. Creating appearance streams is a huge amount of work which many developers have hidden from, though a complete forms solution must do so.

[Guest]

We have new findings so far: the fdf file we create works very well with Adobe Acrobat.

If the fdf and pdfs are saved locally and in one directory we have no issues. However we cannot bring the fdf to properly load data the pdf from our servers.....

Our small example:

%FDF-1.2

%вгПУ

1 0 obj

<<

/FDF <</Fields [<</T (name) /V (My name)>> <</T (address) /V (My address)>> <</T (city) /V (My city)>> <</T (phone) /V (My phone number)>>] /F (template.pdf)>>

>>

endobj

trailer

<<

/Root 1 0 R

>>

%%EOF

If we change /F (template.pdf) to /F (http://localhost/template.pdf), Acrobat says that the pdf wants to open your fdf and loops at this question...

The FDF Specification was not very helpful so far.

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/fdf_data_exchange.pdf

[try67]

If the file is opened using Acrobat or Reader then you can load the FDF directly from the URL, like this:

http://example.org/doc.pdf#fdf=http://example.org/doc.fdf

[Guest]

Thanks for the last info... My colleague has configured his browser in a way, that the pdf is opened directly in acrobat....

The PDF opens, but the FDF data is not loaded.

Update:

F << /FS /URL /F (http://localhost/inthepro/template.pdf)>> >>

Result: "This pdf file is attempting to launch ... Are you sure you want to continue?" loop.

[Guest]

We have found some info about XFDF, now I am trying this:

<?xml version="1.0" encoding="UTF-8"?>

<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve">

<f href="http://localhost/template.pdf" />

<fields>

     <field name="name"><value>Joel</value></field>

     <field name="address"><value>Geraci</value></field>

     <field name="city"><value>StadtX</value></field>

     <field name="phone"><value>494651</value></field>

</fields>

</xfdf>

with still no success...... "this pdf is trying to launch ...xfdf"

Any ideas?

[Test Screen Name]

You seem to have confirmed that your server software is at fault. This problem is nothing to do with the FDF.

[Test Screen Name]

Do you have a web server on localhost?

[Guest]

Last update:
Since the issue is urgent and we were not able to find a working solution, my colleague has started to create a workaround: a button that loads data from our server. In case a client would open the pdf with Acrobat viewer he still would be able to use it.
Preliminary result: Button seems broken, no data is fetched from the server (we see the server logs), however, the forms are working now.

Our "working scenario" now:re-save the original pdf as pdf 1.4, throw it into

1. re-save the original pdf as pdf 1.4throw it into

2. throw it into pdfkt for repairment (so that our server script accepts it)open the pdf again in acrobat and edit some of the form elements,

3. open the pdf again in acrobat and edit some of the form elements

4. throw it again into pdftk for repairment (now much faster)

5. Works.....

Thus the problem is not our server-side script, but some format problems in pdf....

This looks like a temporary solution however. Thus I am not makring this issue as solved.

@ Test Screen: we have a dedicated life server, and I have a test server for testing purposes.

[Test Screen Name]

just checking you weren't trying to use a localhost URL to reach local files directly. Often tried.