Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

Target Version Reference

LC Designer ES (8.1) introduced a new feature called Target Version to help you design forms for use in specific versions of Acrobat/Reader. Although new releases of Designer usually support most new features introduced in new releases of Acrobat, there are still some differences and the Target Version feature will help you ensure that your form isn’t using a feature that isn’t compatible with the version of Acrobat/Reader that you’re targeting (the version you expect the users of your form to use).

You can set a form’s target version by using the “File menu > Form Properties > Defaults > Target Version” property.

For example, the “Lock Fields After Signing” feature of digital signature fields is not supported in versions of Acrobat/Reader less than 8.0. By setting your form’s target version to “Acrobat/Reader 7.0.5 or later”, Designer would issue a warning (in the Warnings palette) about this fact if you placed a digital signature field on your form and checked the “Object palette > Document Signature > Lock Fields after Signing” box.

The Target Version Reference document (under the “Develop” tab) details the versions of Acrobat/Reader that are compatible with Designer features from version 6.0 to 8.1, incl. This should help you ensure that your forms are always compatible with the versions of Acrobat/Reader you expect your target audience to use.

Posted by Stefan Cameron on April 18th, 2008
Filed under Acrobat,Debugging,Designer
Both comments and pings are currently closed.

16 Responses to “Target Version Reference”

  1. Adam Rothschild on April 18th, 2008

    Stefan,

    I’ll first off apologize for posting an unrelated comment to this specific post. From my Google searches, you seem like the resdent pro, so I was hoping you might be able to help me out.

    I’m fairly new to LiveCycle Designer, and am in the process of creating a dynamic form (the form contains expandle text fields and floating fields that populate based on what the user enters into the text fields). The form also has a signature field, for which our user community will use ApproveIt for Desktop software to digitally sign.

    The issue I’m having and need some guidance on is the validation of the signature field. It seems that since the form is dynamic, once the form is signed, and saved, when the signed copy is closed and reopened, the signature comes up as invalid. I assume this is becuase the dynamic elements on the form are rendering at the time of opening and this causes the validation of the signature to fail because it is recognizing that some type of modification has occurred. I’ve saved the form as a static PDF and this seems to take care of the issue, but I can’t afford to lose the dynamic properties of the form.

    Is there a way to have a dynamic form with a digital signature that will still validate ok after reopening the signed copy of the form?

  2. John Nesbitt on April 20th, 2008

    Adam,

    Stefan’s previous article discussing the protection of the XFA model might be of some assistance here:

    http://forms.stefcameron.com/2006/12/07/better-form-design-with-xfa-25/

    John.

  3. Adam Rothschild on April 21st, 2008

    Thanks John,

    That article looks like it pertains to the issue I’m having, but the coding is a little bit beyond me.

    If I create a blank form and the only thing I add to the form is a document signature field, if I save it as a dynamic PDF, I have the same issue with the invalid signature after opening the signed copy. What would I need to add to the code in order to resolve this issue?

  4. Stefan Cameron on April 21st, 2008

    Adam Rothschild,

    What is making you think that the signature has been invalidated once you re-open the signed and saved dynamic PDF form? It’s possible that the signature isn’t invalid, just that Acrobat is detecting some changes to the form on open and is indicating that what you’re seeing may no longer be the version of the PDF that was signed.

    One possible reason for this is that you’re using Designer 8.1 and you’ve specified that scripting changes should be preserved automatically via the “File menu > Form Properties > Defaults tab > Scripting > Automatically option”. This would cause the signature to break.

    If the option above isn’t available to you (you’re using a version of Designer older than 8.1), then you should be careful that any scripts associated to events like “Initialize”, “Form:Ready” and “Layout:Ready” (which are fired when the form opens) aren’t changing the form once it has been signed. You can check a signature field to see if it has been signed by accessing the AcroForm Field associated to the signature field and checking its signatureValidate() function return value:

    var digSig = event.target.getField("form1[0].#subform[0].SignatureField1[0]"); // this gets the AcroForm Field dig sig object
var status = digSig.signatureValidate();

if (status == 0)
    // not signed
else
    // something else (see the API documentation)

    The example above uses JavaScript and assumes that the signature field is located within the first page subform inside your form. To help with the SOM expression, you can use my AcroForm Field Name Generator script:

    var digSig = event.target.getField(GetFQSOMExp(SignatureField1));

    As for the status codes, you’ll need the JavaScript for Acrobat API Reference (look under the “Documentation” tab).

  5. Alyse on June 5th, 2008

    I’m trying to find the “Develop” tab in LiveCycle 8 that you’re referring to for finding a “Target Version Reference” document that lists what LiveCycle 8 features work with what Reader versions. Can you give me details on where to find that Target Version Reference document? I’m obviously not looking in the right spot for a “Develop” tab (I’m looking in Adobe LiveCycle, with a PDF form open. Also looked in the application window itself, without a doc open.

  6. Stefan Cameron on June 8th, 2008

    Alyse,

    If you follow the link I provided in my post, you’ll get a page titled, “Adobe LiveCycle ES Documentation”. On that page, not far from the top, in bold, you’ll see “Browse LiveCycle ES documentation”. Just under that, you should find a row of “tabs”, one of which is named, “Develop”. Click on that tab and scroll down a little until you see “Target Version Reference” under the “Developing forms using LiveCycle Designer ES” heading.

    This link should get you straight to the Target Version Reference PDF but I don’t know how long it will remain valid (I don’t like to point to documents directly because the links change sometimes).

  7. Alyssa on June 9th, 2008

    Hi Stefan,
    I’m trying to use the digSig and status code you detailed above just as you have it written, but I think I’m missing something. Hoping you can help me (as I’m sure you can)! Basically, I’m trying to lock specified fields when a document is signed (in scripting object), and keep them unlocked (or unlock them) if it’s not signed. I’m currently using LiveCycle 8.1, but we’re running Adobe 7.0.8, so I don’t think the Lock Fields After Signing will work. Just to mention also, there will be 3 signatures on this document, all with different specifications for locking or unlocking fields.

    Here’s what’s happening. I have a text field set to take a value based on the status of the signature field (which I’ll be using in a workflow process outside of Adobe). 0 if not signed, 1 if signed. It defaults to 0 just perfectly, but even after the document is signed, I re-intialize that text field (on Sig Field exit) and the expression is evaluated to 0 (the ‘else’ below). It’s quite possible that I’m missing something small, since I’ve learned everything I know about coding for Adobe Forms by reading your posts and reading other online materials. So I’m hoping it’s something obvious!

    Anyway, here’s the code that I have (message boxes are there just for testing purposes):

    var digSig = event.target.getField(“CalMaintForm[0].Footer[0].Perform[0].PerfBySig[0]”); // this gets the AcroForm Field dig sig object
    var status = digSig.signatureValidate();

    if (status != 0) //Signed
    {
    this.rawValue = 1;
    xfa.host.messageBox(“signed”);
    CalMaintForm.variables.LockAllFields.lockFields(); //a script object that I wrote and works fine when used in conjunction with other fields.
    }
    else
    {
    this.rawValue = 0; //Not Signed
    xfa.host.messageBox(“not signed”);
    }

    Any ideas? The only other thing I thought is that our signature handler is part of a document management system that we use and maybe that behaves differently than others…?

    Any help you could give would be great! Thanks for all of the posts. They’ve been so helpful!

    Thanks!
    Alyssa

    When using: xfa.host.messageBox (this.somExpression); I get the following expression: xfa[0].form[1].CalMaintForm[0].Footer[0].Perform[0].PerfBySig[0] – I also tried using this in the code above, but I get “digSig has no properties”.
    }

  8. Stefan Cameron on June 14th, 2008

    Alyssa,

    If I understand correctly, this script is set on the signature field’s Exit event and the intent is that the text field’s value is set to “1” if the signature field was signed. If that’s the case, I’m wondering if the problem could be as simple as the fact that you’re attempting to set the value of the text field using “this.rawValue” which is actually attempting to set the value of the signature field since this script is executing on the signature field which means that “this” evaluates to the signature field, not the text field. Let’s say the text field’s name is “MyTextField”, then you would fix this problem by simply changing “this.rawValue” to “MyTextField.rawValue”.

  9. Nathan on June 25th, 2008

    Stefan,

    I have my target version set to 8 or later and would like the form to warn and closeout to users who open with 7 or earlier. Is this functionality available?

    Thanks,

    Nathan

  10. Nathan on June 25th, 2008

    Stefan,

    I currently researched and pieced together a solution:

    if (xfa.host.version.split(“.”)[0] <= “7”) {
    xfa.host.messageBox(“MyMessage”, “MessageHeader”);
    app.execMenuItem(“Close”);
    }

    This works but causes the reader to crash after closing the document. Which is fine by me since I don’t want them to use that reader anyway. Do you have a better solution?

    Thanks again,

    Nathan

  11. Stefan Cameron on June 25th, 2008

    Nathan,

    Unfortunately, I don’t know of any better solutions. Since app.execMenuItem(“Close”) seems to cause Reader 7 to crash, you might want to simply issue the warning message and leave it at that. That being said, with the target version set to 8 or later, Acrobat/Reader 7 should be automatically issuing a warning message that a newer version of the application is required to use the form. Is it not doing that? Another suggestion could be to have a special page that shows the message about Acrobat/Reader 8+ being required that’s always hidden and if you detect version 7 or less, you hide all the other pages and show that page so that the only thing the users see on your form is a message to use version 8+…

  12. Nathan on June 26th, 2008

    Stefan,

    Adobe is displaying the the automatic warning messages, but after pressing ok or cancel it was still allowing form access. So that’s why I was trying to close the doc. I like the idea of toggling what pages are visible based on version number and may go with that. My warning message before the close was just a statement that the document will now close and you may reopen it after upgrading.

    And thanks again, I just started designing and coding adobe forms 4months ago and have found your site very helpful, most questions I had I was able to research on your site and find a solution.

    Nathan

  13. Anthony on July 10th, 2008

    Hi Stefan

    I am having problems using digital signatures in repeatable subforms. These subforms are added / removed by buttons in which the user presses.
    The subform contains a table with various fields of which one is a digital signature.
    When changing the subform to a repeatable one the digital signature has a red cross icon with the following problem:

    The document signature field is repeatable
    This document signature is inserted within a repatable subform. The document signature may become invalid when the form is rendered as a Dynamic PDF form because the number of objects can change. You can either move the signature field out of the subform or use a data signature in the form.

    When previewing the form the digital signature dissappears and is just blank.

    I tried using a data signature but this does not show up on the form as signed.

    Basically per instance of the subform the person filling it in needs to sign to verify the content of whats in the subform. Any ideas??

    Thanks

    Anthony

  14. Stefan Cameron on July 22nd, 2008

    Anthony,

    Sorry for the late reply. I had to ask some of my colleagues about possible solutions to your problem. I sounds like your best bet is to use data (XML) signatures since these can repeat and can sign specific portions of form data. Traditional digital signatures cannot do “sectional form signing” which is what you need since each instance of the subform must be signed separately.

    XML signatures can be seen in the Signatures palette in Acrobat. Note that they aren’t validated automatically: When you view them in the Signatures palette, you can right-click on each one and choose the “Validate Signature” menu option.

  15. Aditya on October 27th, 2008

    Hi Stefan,

    I am new to LiveCycle designer and I tried using the above script. It doesn’t seem to work. Do you know of a script that would help me validate if the status of a signature field is signed or not.

    I have two signature fields for an employee and manager. When the employee opens a form he should enter his details and sign the form. When signed, the manager’s signature field should appear. I have managed to get that to work. However, as a part of the form the employee cannot enter details in the manager’s fields. This is where I am having a problem. I have locked the manager’s fields in the form initialize event and opened the same fields when the employee signs.

    In the real world when the user saves and re opens the form’s initialize event kicks in and the manager’s fields are locked again. The signature check script would help me overcome the problem.

    Thanks

    Aditya

  16. Stefan Cameron on November 3rd, 2008

    Aditya,

    You can programmatically check the status of a digital signature field by accessing the AcroForm signature field that relates to the XFA signature field and then using it’s signatureValidate() method:

    var digSig = event.target.getField(GetFQSOMExp(SignatureField1)); // *

if (digSig)
{
    var status = digSig.signatureValidate();
    var message = "";

    switch (status)
    {
        case 0:
        case 1:
            message = "not signed";
            break;

        case 2:
            message = "invalid signature";
            break;

        case 3:
            message = "valid but identity of signer cannot be verified";
            break;

        case 4:
            message = "valid signature";
            break;

        default:
            message = "error";
            break;
    }

    xfa.host.messageBox("Signature status: " + message);
}
else
    xfa.host.messageBox("Unable to locate signature field in AcroForm DOM");

    * The GetFQSOMExp() function is available in a previous post on the AcroForm Field Name Generator.