Disable your form in older versions of Reader

When designing forms that require newer versions of Reader, you may want to be intentional about the experience users get when they open the form in older versions of Reader.  Today if you target a form for
Reader X and open it in Reader 9, you get this dialog:

After you’ve dismissed the message, Reader goes on to display the form as best it can.

The problem is that "as best it can" could lead to a very poor experience.  If you have functionality in your form that relies on a more recent Reader, then in all likelihood, your form is broken.  This could manifest itself in any number of ways.  e.g. Validations not firing correctly or the form not displaying correctly. 

As a form author, you’d prefer to prevent the user with an old version of Reader from having any interaction with the form.  No experience is better than a bad experience.  The topic for today is a design pattern to author a tailored experience for the user with an older Reader.

Design Pattern

There are probably several ways this can be done. I’ve chosen to add a version-checking subform below the root.  This version-checking subform has the following properties:

  • Contains content that warns the user that their version of Reader is not new enough
  • Points the user to the reader update page
  • Has a form field with the required Reader version number
  • Has an initialization script that compares the Reader version to the required version
  • If the Reader version is not new enough, the initialization script will remove instances of other subforms below the root and make sure the version checking subform is visible.
  • If the Reader version is new enough, the initialization script will add instances of other subforms below the root and hide the version checking subform

For this script to be effective, the other subforms below the root must be defined with occurence settings where the minimum is zero and the initial number is also zero:

I have attached a sample form that uses this technique. The form is targeted for Reader 10.  If you open it in version 9, you will get the version check warning experience.

5 Responses to Disable your form in older versions of Reader

  1. Jono says:

    Hi John, I did something similar but with hide/show logic. It also does a reverse check (if that’s a term) to see if JavaScript is enabled.

    I’ve got a sample here: https://acrobat.com/#d=ymlPW2HMEWTn5lmxLFkDKA

    I’ve been meaning to upload it to Cookbooks but haven’t got around to it yet. :)

    • Jono:

      Yep, show/hide works as well. And the JS check is cool.
      I was working with an additional constraint — the customer problem that I looked at had run-time errors when the form was loaded in an older reader. So I didn’t want the subforms to be created and logic executed. That’s why I chose add/remove subform over show/hide.

  2. Bruce says:

    Hi John,

    I suspect I already know the answer to this but was wondering if you have ever had the need to disable a form because a non-Adobe viewer is being used.

    Recently we have had a few problems with Foxit Reader, which according to it’s xfa.host.appType seems to claim to be Acrobat (or at least Exchange). The property xfa.host.validationsEnabled is returned as a Number not a boolean, which seems to be the only difference.

    Foxit Reader seems to have some XFA compatiblity so gives the user the feeling the form is working but has enough incompatiblities to cause us problems.


    • Bruce:

      I haven’t run into this before. On the one hand, it’s encouraging to see Foxit support XFA functionality — after all it is a public spec. But on the other hand, they also need to be good citizens and give you the means to identify which viewer you’re using.
      Assuming Foxit also supports portions of the acroforms object model, is there anything there that will give you a clue?
      Barring that, the other thing you could try is to poke into areas of the xfa object model that they are less likely to have implemented. e.g. check typeof xfa.signature


  3. Niall says:

    // Just my two cents worth.


    Third-party readers are more trouble than they are worth. I have tested many readers and most fail at some point. The trouble, as you have said is that they tend to fail silently, so that the user is not sure what the situation is.

    I have some tests on Apple Preview here: http://assure.ly/hd4jFh. I have also tried FoxIT this morning and while you may have “some” success with a Static PDF (XFA form), Dynamic XML Forms will not work (even simple buttons won’t click).

    FoxIT reader seems to have better support for AcroForms.

    I think that if there is a potential that your users may use a Reader other than Acrobat or the free Adobe Reader, then you should include a note/warning in the form. While you can try and script a solution, a static text object is probably the safest.

    Don’t get me started on mobile readers ;-)