Adobe Embed PDF API - XDP Forms

[crich2784]

Does anybody know how Adobe Embed PDF API behaves with XDP - Interactive/Static Forms?

Do they work?  If yes,

Does it respect javascript?

Does it respect required fields?

Here is the demo:

https://documentcloud.adobe.com/view-sdk-demo/index.html#/view/FULL_WINDOW/Bodea%20Brochure.pdf

It would be great to have a browser based solution for viewing XDP forms.

We have been using pdf.js viewer:

https://mozilla.github.io/pdf.js/web/viewer.html

You can upload an Interactive/Static form and it is fillable.  Not all things are respected, like buttons and some javascript.  With this demo, it is easy to test!

[Joel_Geraci1 · Accepted solution]

Dynamic XFA forms are not supported and only the AcroForm fallback is supported for Static XFA. At this time, no JavaScript or FormCalc is supported and no field properties are supported.

[crich2784]

Joel, nice to hear from you. 

Is there a public roadmap?  If not, is there a non-public roadmap?  You can probably guess the question . . . any plans for XFA based forms?

[Joel_Geraci1]

I haven't seen the roadmap but to the best of my knowledge, we're targeting PDF 2.0 with Embed API and I suspect you know what that implies.

Also, I don't recognize your screen name or I'd have said "Hi" too.

[crich2784]

@Joel_Geraci1 it's Charles Rich here. 

I have another question for you.  We are using renderForm service and merging XML data into an XFA based form.  As you can probably guess from my previous posts, when rendering, it behaves like an AcroForm - fields fillable and such when viewing in pdf.js or Adobe Embed API.

However, as you also probably know, the data is NOT appearing.  I can download the form and view it in Acrobat and the data is there!  I guess in the XFA DOM.  But, Acroform structure, its' not there.  

Is there a way to prefill using FDF with AEM Forms apis?  Basically convert this XFA based form into an Acroform?  These are not dynamic forms, btw.  Simple fillable forms with very little javascript.  

[practicalPDF_JoelGeraci]

I actually think it's Acrobat that will cross populate the AcroForm and XFA dictionaries but there may be a switch you can throw to do it in AEM. But if there is any JS at all in those forms, you can't use Embed API. I'm curious to find out what field JavaScript is supported in pdf.js.

[crich2784]

Yes, most of the values for fields are coming over fine.  And, Joel, you hit the nail on the head.  We have js that is populating options in dropdown.  Instead of populating via a script, I put together an FDF file and merged it using pdfbox and pdftk.  When viewing the PDF in Acrobat, the options were in the dropdown, yay!!  But, viewing the PDF in pdf.js the dropdown wasn't populated.  I even tried the Java api and directly populated the dropdown with pdfbox - didn't work either.  I guess pdf.js is not fully implemented.  I haven't tried in Adobe embed - seems too hard right now.  However, the bigger issues are the required fields and some of the validation patterns.  We're ditching pdf.js and forcing a download of the PDF into Acrobat - sticking with XFA for the moment.  Not the best user experience but, acceptable for the moment.  To submit, we populating the submitURLs but, the user session missing in Acrobat is a problem so, the submission is a little hacky.  

[practicalPDF_JoelGeraci]

If you have AEM Forms, I don't understand why you are asking the users to fill out the form as a PDF at all. Why not use adaptive forms and only populate the PDF at the end?

That said, if you need a PDF style filling experience, you're better off using Adobe Sign and leveraging the FORM_FILLER participant type. Adobe Sign works consistently across all surfaces and will do calculations and field validation.

[crich2784]

Dude, how many personas do you have!?

Quick answers. They have almost 2000 PDFs.  We are proposing to go adaptive with the key forms.  This is a stop gap.

And, Adobe sign? Per transaction? They've owned LiveCycle for 20+ years and have a sweet renewal. There's no way to convince them of another model. It's all internal.

[practicalPDF_JoelGeraci]

I just noticed the randomized screen name and corrected it. Same persona. It's all internal? With that being the case, I'd just work on strategies that force the user to open the file in Acrobat or Reader on the desktop.

[Mayank_Gandhi]

@crich2784  I assume you have a jee server as you are mentioning about the Forms API, just make sure PDF/XDP has schema bound to it and the schema is obtained from the xml you are trying to fill. This would work like a charm. You can use sample xml as well to bind the form in designer

[crich2784]

All OSGI - we are migrating a customer from LiveCycle to OSGI only.

[Kosta_Prokopiu1]

Hi @crich2784 ,

the use case of interactive, dynamic PDF forms as a data capture tool is a thing of the past. Apart from Adobe Reader/Acrobat, no other PDF Viewer supports it any more. Replacing them with AcroForms would mean to re-build them - and AcroForms are not exactly "latest" technology either.

When you migrate from good old LiveCycle JEE to OSGi only I would recommend to also reform the data capture, using what Adobe sees as best practice. Adaptive Forms with Document of Record. Your XDPs would still be usable in the DoR generation and can serve as base for creating the adaptive forms..

[crich2784]

Thanks for the observations and pointers.  They have almost 2000 PDF forms. We are proposing to build  adaptive forms to replace key forms. If you have an affordable way to convert them all, let me know.  Simple math - 2000 * 8hrs * hrly rate = unaffordable in my clients opinion.

[GirishBedekar]

You can use the automated forms conversation service to convert pdf forms to adaptive forms 

[crich2784]

Girish,  I'll check it out and see how they convert.  I have to be honest, the setup of the conversion service looks daunting!  We'll see . . .