PDF forms in Apple Preview

Posted in: LiveCycle- Feb 12, 2011 4 Comments

René Magritte’sThe treachery of images” is one of my favourite visual statements. It challenges me to think about what I am putting down on paper. I think that it is also relevant to this topic:

This is not a form (when opened in Preview)“.

If there is a possibility that your forms may be opened by users with a Mac, then this information is for you!

First off, here we are talking about forms that were developed in Acrobat (called AcroForms) or developed in Adobe LiveCycle Designer ES2 (called Dynamic XML Forms and Static PDF Forms). Native PDFs, like a standard document should behave perfectly in Preview.

This is a hotly debated issue across the web. I am not necessarily presenting anything particularly new here, I am just outlining our experiences and grouping the main points in one location. There is a detailed explanation and script solution on Joel Geraci’s blog.

Apple Preview

As standard a Mac comes with an Apple application called Preview. This is quite a handy application for viewing images, such as JPEG files. You can also use Preview to view a PDF, but this is where your troubles can start.

What will your users see in Preview?

There will be a number of problems when viewing a form in Preview. For example you cannot open a Dynamic XML Form in Preview. All you will get is the “Please wait…” message.

For AcroForms and Static PDF Forms, most of the problems are common.

  • The form will look okay, but when the user clicks in a field, it will appear as an object hovering over the page. It will also be offset from the actual visual appearance of the field. The amount of offset appears to be more in Static PDF forms, compared to AcroForms. This results in a poor user experience, but is not a serious problem.
  • Of much more concern is that some form objects will not work at all. For example the date picker for a date field will not work.
  • Buttons will not work, so while the user can see the button and even click it, nothing will happen. Not a good user experience.
  • JavaScript/FormCalc script will not fire, so if your form includes calculations or any other similar types of functionality, it will not work.

Basically any AcroForm or Static PDF Form will not function as intended by the designer. The fallout from this will depend on the nature and complexity of the form.

What will you see when the form is returned to you?

Probably nothing! Aaaggghhhh!

Yes believe it or not, when you open the returned form back in Acrobat or Adobe Reader, it will appear blank as if the user didn’t complete the form at all. However when you click into one of the fields, its contents will magically appear, but disappear again when you click out of the field. Great!

All is not lost though, Joel has a script solution that allows you to correct this “feature”. When you run the script in the returned form, it forces the form objects to be regenerated and all of the data is visible again.

This is an useful solution, but I think that we are still left with the problem at source: Preview and the poor user experience.

Dynamic XML Form solution

Sorry, there isn’t one. The Dynamic XML Form just won’t open in Preview.

Static PDF Form solution

Hmm…, sorry there isn’t a solution here either. Yes, the form opens in Preview, but script will not fire, so you cannot interrogate the viewer type (the application used to open the form). This could potential identify that the form was opened in Preview and then display a message to the user warning them to use Acrobat/Reader.

You can download a form here that I was working on. It is a Static PDF Form with script to determine the viewer type. When you open it in Acrobat/Reader you will see this information in the top right corner. In addition you will see that the date is pre-populated with the current date. Great!

However now if you open the form in Preview, the viewer information is not available. Not good!

This makes it very difficult to determine that the form was opened in Preview and therefore it limits your ability, as a form designer, to do something about it.

AcroForm solution

The situation is a little bit better with AcroForms, but not much.

Firstly you will still have the same problems with script in the AcroForm not firing when it is opened in Preview. This is a big limitation. Here is an AcroForm that we were working on. When it is opened in Acrobat or Adobe Reader, it works perfectly. However when opened in Preview none of the script works, buttons, calculations, etc.

This really hits the user experience.

The one glimmer of hope is a solution that Dave Merchant recommended.

It involves using Acrobat’s Layers to provide a warning to users if they have opened the AcroForm in Preview.

This means that at least you can tell the user to open the form in Acrobat or Adobe Reader. This is a big improvement.

Here are some screenshots showing how to set up the layer in your AcroForm. The layer is set with a default visibility of “on”, but will not print or export:

Step 1 – import the warning message graphic as a layer:

Step 2 – set up the warning message graphic where you want it to appear:

Step 3 – the warning message is now a layer in the form, which you can control using script:

Step 4 – set the layer properties:

You will also need a small bit of document level script:

var OCGs = this.getOCGs();
for (var i=0; OCGs && i<OCGs.length;i++) 
    if (OCGs[i].name == "warningLayer") OCGs[i].state = false;

I really appreciate Dave’s help with this solution!

Here is a version of the AcroForm, with the warning layer. Try it out in Acrobat, Adobe Reader and Preview. It works!

Other “viewers”

To be fair, this is not just an Apple Preview problem. Other third party viewers may also exhibit the same problems. It is safer to stick with Acrobat or Adobe Reader when filling in forms.

My recommendation

At the end of the day, if it is likely that your users will open your form in Preview or other third-party viewers, then I would recommend a static text instructing the user to use Acrobat or Adobe Reader.

This does not depend on script and will always be visible.

This advice would stand, until Preview is updated to handle PDF forms better.

4 Responses to “PDF forms in Apple Preview”

  1. George Johnson says:

    Nice article, Niall.

  2. Jim Demers says:

    Amazingly, still not fixed in 2013.
    Conveniently for Adobe, the only solution is for everybody to use Adobe software. I believe that Adoobe has patented key aspects of the pdf format, and that Apple can’t (or won’t) get a license.

    • NiallODonovan says:


      I genuinely don’t believe that is the case. The PDF is available as an ISO standard.

      In 2008, Adobe published a Public Patent License to ISO 32000-1 granting royalty-free rights for all patents owned by Adobe that are necessary to make, use, sell and distribute PDF compliant implementations. (source: Wikipedia).

      The main issue with Dynamic PDF forms is that they are created in LiveCycle Designer, which wraps the XML form in a PDF wrapper. This means it is different from a native PDF. The Apple Preview application just can’t handle it.


Leave a Reply

You must be logged in to post a comment.