Internal html attachment as a responsive version of the PDF form

[Piotr Smolen]

Hello,

Apart from the undeniable advantages, PDF forms have one significant disadvantage for me, namely they are not responsive. In the era of digital accessibility, smartphones and the need to comply with the WCAG guidelines, this is a problem, especially for public institutions.
On the one hand, PDF forms are great, but filling out the most brilliant form on a smartphone screen is already a challenge, and if a person with vision problems is to do it, it is already a cosmic challenge. Of course, you can create several versions of the same form, but we want to avoid that, and besides, there will always be a person who requires even more specific screen settings and operation. On the other hand, resigning from PDF in favor of forms in another format is virtually impossible. For now, there is nothing on the horizon that will surpass the popularity and accessibility of PDF, especially if we still need a document with intelligence embedded in scripts that can be operated on different platforms.

So I thought:
Or maybe add an html document in the PDF form as an internal attachment, which is a responsive version of the main form. It's trivial, I add and there is such a document, I can launch it with a button from the main form or a script launched when opening our PDF form. The system will open it with your default browser. One line of code.

So far, however, I don't know how to go about it (and if it's even possible) to:
1. After opening such an html document, pre-fill it with data from the main PDF form (or maybe even before opening it),
2. After filling it in the browser, when closing, transfer the data from this form to the other side, i.e. to the source PDF form. After all, as an attachment, I can add, for example, a spreadsheet, which, after filling out and closing, can be saved in a changed version as our attachment in a PDF document.

Can anyone suggest something on this?

[Test Screen Name]

Adobe have moved in a rather different direction. They basically accept that HTML forms are much better for filling and have big-ticket server side processes to convert a PDF form dynamically into a live and responsive HTML form.

[Piotr Smolen]

Yes, I know, but here the problem is a bit different. And most importantly: PDF forms with attachments (e.g. html) can be created in Adobe Acrobat Pro without spending a lot of money on corporate solutions.
In addition, these forms are to be accessible to ordinary people from the level of the operating system, web browser and Acrobat Reader. And these people don't need to know that there is such a thing as an operating system and a browser 🙂

[Piotr Smolen]

The task of filling out the html form before opening it turned out to be simple too 😉

The problem remains how to fill in the html form in the web browser and transfer the data from the fields to the main PDF form.

[Thom Parker]

AFAIK, there is no mechanism for transfering data from HTML displayed in a browser into a PDF, which I'm assuming would also be loaded in the browser. It's not that this couldn't be done. And in fact there is an API in the Acrobat JS model exactly for this type of thing. 

https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/JS_API_AcroJS.html#hostcontainer

It is used to send messages between the containing HTML and a PDF being displayed in the HTML. Kind of the opposite of your situation. Anyway, it's not currently supported by any browser that I know of.  

It's possible that the Adobe Embed API could work for this type of thing, but don't know for sure:

https://developer.adobe.com/document-services/docs/overview/pdf-embed-api/

The problem with trying to do this sort of thing on the user end is that neither the device nor the browser can be relied on to provide the necessary functionality. So the most reliable way to transfer data from an HTML to a PDF is to do it on the server. Which has always been the case. 

[Piotr Smolen]

The PDF form is supposed to be opened in Adobe Reader (or Foxit Reader because it works quite well). I use scripts to check how the document was opened and inform the user that it is better in Adobe Reader 🙂 Support for scripts in PDF forms from the level of browser plug-ins is symbolic and cannot be relied on. Then, from the level of the form in Adobe Reader, the script is to be called html. I've already mastered it, including modifying the html file that is an internal attachment of the PDF form. And this is where the feedback from the html form to the PDF form is missing.
I fill out an HTML form and.... just close my browser and lose everything.
Without this icing on the cake, I lose the idea in its entirety. It is a pity that it does not work like, for example, a spreadsheet which, after being modified and closed, automatically "saves inside the PDF".

But I will look for some solution, it doesn't have to be elegant. It's just supposed to work.

You gave a spark of hope in these links 🙂

[Thom Parker]

So you must be launching the HTML attachment from the attachments panel in Acrobat?  In this case the HTML file is opened by whatever browser is installed locally. To do this, Acrobat saves the HTML file to a temporary location. If the file in that location is modified, then Acrobat Pro (or Reader if the file is enabled for it) saves the modified file back to the attachment. Browsers don't save HTML files in the same sense that Excel, NotePad, or other content apps do. Browsers by nature are intended to load remote data that cannot be written back to directly. However, since the HTML is in a temporary file location, the user could, in theory, manually save it. The file system path should be in the browser URL field. 

Of course this is a very clunky technique and doesn't work for mobile devices.  

[Thom Parker]

There is another solution.

You could write an Acrobat plug-in that has it's own HTML browser. Such a plug-in could display the HTML and transfer data from the attachment into form fields on the PDF.  But your form would only be usable on systems where the plug-in is installed.