26

I work for a company that has hundreds of forms in fillable PDF format on our website. We run into issues constantly because web browsers love to open PDFs in browser instead of opening the files in the native Adobe Reader application.

Users download the form and their browser opens the file in a new tab. They end up filling out the form in the browser and then try to use the JavaScript submit button at the bottom which does nothing because browser block JS activity in PDFs. If they haven't given up by this point, they'll save the file to their desktop but the forms don't save what was filled out in the browser and they become even angrier.

What is standard practice for this sort of thing? Normally, I recommend replacing fillable PDFs with regular web forms but a good number of these forms are longer, there are a ton of them, and most of them are updated quite often making web forms less than ideal.

I've looked at DocuSign-like products which I've never used before but appear on the surface to be better equipped to manage form distribution and collection but I'm unsure if this is best practice (especially considering the paywall on some of the bigger name products) or if there's a solution I haven't thought of.

  • 4
    There is no standard practice. – Rob Dec 10 '19 at 20:22
  • 7
    I sympathize. As a tech. support person, I deal with this problem a lot. No simple solution because in many cases the PDF output is required - or a pixel-level equivalent - to meet government or other requirements. I have started - but far from finished - a project for a customer centering around a similar issue. No easy answer. – manassehkatz-Reinstate Monica Dec 11 '19 at 3:27
  • Could you have a bit of JavaScript on the link to the form that displays a message instructing the user to save the PDF locally before opening it in Acrobat Reader? Another possibility is to add the "download" attribute to the link, which should force the web browser to download the file rather than opening it in the browser. It's not foolproof, as some people have their web browser set as the default PDF viewer, but it might help. – Wally Hartshorn Dec 12 '19 at 14:25
  • 1
    I used to make web forms that would use pdftk to fill the PDF (so the output would look the same), but that's an enormous amount of work. – Moshe Katz Dec 12 '19 at 14:48
  • 2
    @MosheKatz - That's essentially my problem. There are too many PDFs and they need to be updated too often for standard web forms to be an option. – TheIronCheek Dec 12 '19 at 15:28
18

Normally, I recommend replacing fillable PDFs with regular web forms

I think overall, yes, that would be the ideal solution, but you noted some of the the issues with this, which includes how to handle all the existing content already made.

We run into issues constantly because web browsers love to open PDFs in browser instead of opening the files in the native Adobe Reader application.

By allowing the browser to handle the PDF file, you are leaving it to each users individual browser settings (e.g. open PDF in browser, or download). You have no control this way.

What is standard practice for this sort of thing?

You need to take control of the entire viewing experience, by adding a PDF viewer that supports PDF form filling, and load the PDF in your viewer. This way you know exactly what the user is doing, and control the entire user experience, and you can test your corpus of files for testing against this particular viewer since you host it.

  • 3
    That looks like a great solution. But I will tell you that having to hunt for pricing is a HUGE TURNOFF. Arguably not being able to simply find pricing for all options is more of a turnoff than the fact that one place that does list a $ amount says "PDFTron license pricing starts at US $4000 per year." Please tell the powers-that-be at your company that the typical small business (and there are a lot of those willing to spend a reasonable amount on software) will turn away with pricing attitudes like that (not just the amount but the "hidden nature"). Just saying... – manassehkatz-Reinstate Monica Dec 11 '19 at 3:23
  • 1
    (the previous comment is about a moderator-deleted suggestion to use the commercial JS PDF viewer developed by this poster's company, which does support form-filling) – Peter Cordes Dec 11 '19 at 8:02
  • 1
    @manassehkatz-reinstate-monica Thank you for the feedback about our site, I have passed it onto the website design team for review. "typical small business (and there are a lot of those willing to spend a reasonable amount on software)" Couldn't agree more, many of our customers are small or startups, that happen to require full control over their users document viewing experience. – Ryan Dec 11 '19 at 18:54
  • 1
    The OP didn't specify whether the people filling out these forms were internal staff or members of the public. If they're members of the public, there isn't any way that I know of to ensure that they're using the right software to open the forms. – Wally Hartshorn Dec 12 '19 at 14:09
  • 2
    @TheIronCheek great additional info. Again, ideally just having web forms is ideal, but if you need to continue with PDF form filling, then embedding a PDF viewer (that supports form filling) should also allow you to completely control the UI/UX, so you could greatly simplify things by stripping down the viewer to minimal components, assuming the web based PDF reader also allows for full UI/UX customization. So you can give your older clients are very controlled seamless experience (no downloading, no uploading, etc). – Ryan Dec 12 '19 at 19:19
10

You could try to force downloading of the PDF, so that it opens in the default application for viewing PDF files instead of the browser.

See this question: How do I force files to open in the browser instead of downloading (PDF)?

  • This runs into the problem that very few PDF viewers support fillable forms. – Mark Dec 11 '19 at 2:57
  • 4
    @Mark the most common PDF viewer for "average users" on desktops & laptops is I believe still Adobe Reader or Adobe Acrobat, which support fillable just fine. I've seen this problem a lot - the problem is the average user on his/her own doesn't understand the difference between download/local vs. in-browser. – manassehkatz-Reinstate Monica Dec 11 '19 at 3:25
  • 6
    Wouldn't forcing the download just cause the file to download instead of open directly? Once the file is done downloading, the browsers prompt the user for permission to open the file and if they click "Open", aren't we back in the same boat? – TheIronCheek Dec 11 '19 at 19:13
  • 7
    @TheIronCheek the difference is: after downloading, the file will be opened by the users default application instead of their browser (the browser is rarely registered as default for PDF). So at least they should be able to save their input. Or allow JavaScript. – SRMM Dec 12 '19 at 13:49
  • 5
    @SRMM In Google Chrome, if you click the downloaded PDF file, it will open in Chrome instead of the default viewer, unless you have the setting "Always open PDFs with system viewer" turned on. – Moshe Katz Dec 12 '19 at 14:47
5

There is no standard practise. You'll have to re-think your process:

Why do your customers have to fill out PDFs in the first place?

Do you just need structured data from the customer? Who needs the PDF later, a government agency? Do you have to provide the customer with the same PDF? Can your company create web forms instead of PDFs? Can you auto-generate the PDFs yourself? Does the customer need to see the PDF exactly as is when filling it?

At our company, this PDF-filling is part of our core business domain, so we have an in-house solution. If it is not crucial to your business, you could buy this PDF-to-web form bridge from DocuSign, HelloWorks et al.

The quick-and-easy way is to force PDF download and demand that your customers use Adobe Reader.

Edit/PS: As PDFs are two-dimensional landscapes, they can be hard to navigate on mobile devices. Zoomed out, you're able to see everything but can read nothing, or vice versa when zoomed in. You have to consider how many users are on mobile devices. The more mobile devices among your customers, the better a web-optimized solution that features real forms. After filling the form, you could present the user with the automatically generated PDF.

  • 1
    There are some documents that need PDFs for government agencies but the biggest reason for the number of PDFs is that it's easy for the company to install Acrobat on an employee's computer and tell them to save their Word doc as a PDF when they're done with it. That and the old "that's how we've always done it" argument. – TheIronCheek Dec 11 '19 at 19:08
  • 2
    You mention forcing the PDF download but my experience is that the PDFs download correctly but then the user just clicks the file from the browser's download previewer and it opens in the browser anyway. – TheIronCheek Dec 11 '19 at 19:10
  • 1
    Another big reason to use PDFs for forms is that many people will just print the form and fill it out by hand. That's probably not an issue if you're creating forms for internal staff to use, but if you're creating forms for use by the public (e.g. if you work for a government agency), you probably have to deal with this. – Wally Hartshorn Dec 12 '19 at 14:20
  • @TheIronCheek You can always .zip the files and ship them ;) It's all just a matter of inconvenience. Really depends how technological your customers are and how much they depend on you. (eg If you're a federal agency, who cares, they are going to fill out a PDF giving them money.) – knallfrosch Dec 12 '19 at 14:35
  • 1
    @WallyHartshorn - that's exactly what happens. We have a ton of older clients who just print the form, fill it out by hand, and mail it to us. – TheIronCheek Dec 13 '19 at 15:08
2

Even if you force users to download a PDF instead of opening it directly, you have no control over what program they use to open it (for security reasons).

Others have mentioned DocuSign (or similar), which have great tooling for not only signing but access control and 3rd-party verification. For most people, this is a good way to go. However the pricing may be prohibitive for certain businesses / use cases.

I recently built a custom signing tool for a large client, who also needed to accommodate a large number of ever-changing documents and save the completed and signed PDFs. As far as I can tell, it's similar to what DocuSign is doing (though not nearly as sophisticated)

The workflow is as follows:

  1. A manager/customer creates the document with signature fields, and uploads it in the application
  2. The application registers the doc for use, and extracts information about the fields to be completed
  3. The end user is shown a web form generated automatically from the metadata.
    • The form shows a background image of the original document
    • The input fields are positioned over their correct spot in the image so it looks like the user is typing directly on the document
  4. The user fills out the form and physically signs a signature section (on a tablet or with a mouse)
  5. The completed form data and signature image are sent back to the server
  6. The application fills in the original file with the data, and generates a PDF
  7. The final PDF and all the form entries (but not the signature!) are saved to the database, allowing admins to search within all completed forms and remove them if ever needed (e.g. HIPPA / GDPR compliance)

However for most businesses, especially those without developers and IT already on staff, building and maintaining a custom app like this isn't viable or cost effective. Between the development, security, and liability, it's generally cheaper (and a better user experience!) to just go with an existing service.

  • 1
    Honestly, I hadn't thought of just writing something myself. The functionality you built is all I'd need too. In fact, I probably wouldn't even need to ability to sign as almost none of the PDFs we have ask for signatures. – TheIronCheek Dec 13 '19 at 15:18
1

I worked on a project many years ago which used downloadable Word documents with form fields and editing protection which disallowed changing anything except the contents of the form fields. If your users will have Word (or maybe LibreOffice – you could do tests to see what the compatibility is like nowadays) then this might be an alternative. I've not seen any browsers which attempt to open Word documents.

  • Something like this may be an option... Office is so widely used that this could work but there's still technically a cost barrier for the clients unless LibreOffice is a viable option. – TheIronCheek Dec 12 '19 at 15:34
  • 1
    I've worked with these types of documents. When everything is done "just right", they're OK. But so often parts are not done quite right... – manassehkatz-Reinstate Monica Dec 13 '19 at 3:19
  • @manassehkatz-ReinstateMonica - What do you mean by "not done 'just right'"? – TheIronCheek Dec 13 '19 at 15:11
  • 1
    @TheIronCheek Just poor general design - e.g., fields not lined up, fields that depend on other fields not changing correctly, fonts not matching between fields, selections that don't make sense. – manassehkatz-Reinstate Monica Dec 13 '19 at 15:26
1

Might be a bit late to this one but having experienced this myself I would genuinely just start moving to Web Forms for this. Others have listed out the major reasons above but to be honest, my opinion on situations like these is:

If there are 2 perfectly usable options where one is open-source and the other is proprietary (e.g. HTML Vs PDF) then go with the Open Source version. Cost will be a winner in the long term, and there's little chance of a feature getting locked down by the vendor behind a paywall or price increase.

In theory Adobe could always pull Form Filling from the standard Adobe Reader in an effort to force people to pay for something like Docusign/Echosign. Doubtful but possible, and then you'll end up having to convert them all anyway.

An advantage to going with a web form for this is the extended functionality and data validation you can perform. Also, if you need to use a pdf further down the line for something internal, you can always use a library to generate a PDF from the web form, the other way round is not as easy.

I would begin with monitoring the GET requests for the forms to identify those that get used the most, and begin converting the most used to the least over time.

  • I agree with you in principle but there are too many forms that are too regularly updated for me to maintain them all as web forms. – TheIronCheek Dec 16 '19 at 14:20
  • In that case it would be worth flagging this up to your line manager and see if they can do something about it. I would argue for (and probably not get) a temp in to do the data entry to a standard template, which you could then overview, edit and publish to keep your hands free for other stuff. The key thing is getting it recorded with your manager that this is an issue that needs fixing, so if it does all fall apart you can point back to the email and say you did try to get it fixed x months/years ago. – DAustin Dec 17 '19 at 11:27
0

Are you able to modify the files at all?

There are some systems that (ab)use the fact that every pdf reader renders differently to detect what PDF reader you are using.

I know I have seen PDFs created before, which if not opened in adobe reader, only display a page asking the user to download the correct software.

Google's currently failing me, but I assume there's some setting you could flip in acrobat in order to make a PDF that would require the user to download adobe's SW.

  • 5
    That message you've seen instructing people to install the latest version of Acrobat Reader is actually the default message displayed when trying to open a PDF that was created using Adobe's LiveCycle Designer (now AEM Forms Designer) product. It creates XML in a PDF wrapper. Web browsers' built-in viewers can't display it, so that message is shown instead. Unfortunately the message is useless, because the user will install Acrobat, then continue to use the web browser to open the file.I haven't found any way to change what the message says. – Wally Hartshorn Dec 12 '19 at 14:17
  • 1
    "I know I have seen PDFs created before, which if not opened in adobe reader, only display a page asking the user to download the correct software." As @wally-hartshorn said, this is XFA (xml in a PDF wrapper) and not only is it a proprietary Adobe technology, but has been voted out of the latest PDF 2.0 standard due to the many issues with XFA. – Ryan Dec 12 '19 at 19:23
  • "There are some systems that (ab)use the fact that every pdf reader renders differently to detect what PDF reader you are using." Can you give a specific example? What do you mean exactly by "system" in this context? – Ryan Dec 12 '19 at 19:24
  • @Ryan do you know of anything that will replace the features of XFA? We use AEM Forms Designer extensively, creating complex "smart" forms with interactive features (e.g. showing/hiding parts of the form based upon whether the user has checked a box), but we haven't been able to find a good replacement for the future. – Wally Hartshorn Dec 13 '19 at 15:12
  • @wally-hartshorn Not in the PDF space, unless you know all your users are using certain installed products (such as in a controlled Enterprise environment). Otherwise you will run into the issues that the original poster and others here are mentioning. Adobe Livecycle has an option to save the XFA forms as "Static forms" which converted them back to "classic" PDF Acro Forms, which is what the original question was about. Ideally, you would use web forms for new content, as myself and others are suggesting, and not forms in a PDF file. – Ryan Dec 13 '19 at 17:55
0

Users download the form and their browser opens the file in a new tab. They end up filling out the form in the browser and then try to use the JavaScript submit button at the bottom which does nothing because browser block JS activity in PDFs. If they haven't given up by this point, they'll save the file to their desktop but the forms don't save what was filled out in the browser and they become even angrier.

This makes me think that there isn't any sort of indicator that users should download and use Adobe Reader, or an alternative program (E.g.: SumatraPDF).

However, there is a way! How about some changes to make the PDF gracefully degrade?
Instead of the button being always present, use JavaScript to add the button.
Alternativelly, a better option would be to replace the contents of a "box" with the button. The "box" could have a warning to save the file or use the "Print to PDF" option on Windows 10 or the browser itself.


Using an actual example, taken from: http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf

Using Google Chrome, you can print the PDF (and if you pick to "Save as PDF", you can send it): Google Chrome - Save as PDF

You can see that the form is filled with random "junk", but filled. It can't be edited later, but it is filled.

In the case of Firefox, it gives a proper warning: Firefox warning (Roughly translated: This PDF document contains forms. Field filling is not supported. - Open with other viewer).


In short: consider graceful degradation and proper warnings/instructions in the webpage and PDF itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.