Acrobat X and XFA 3.3

By now you will have noticed the announcements for Acrobat X — which promises to be a very nice upgrade on the Acrobat and Reader product lines.  Acrobat X includes XFA version 3.3.  In this blog post I will give you an overview of the new features that have been added to XFA forms.

Designer Version

As usual, LiveCycle Designer is bundled with Acrobat Pro. This Designer is the version that went out with the most recent release of LiveCycle.  i.e. this is Designer 9 a.k.a. Designer ES2 — plus some bug fixes. This version of Designer is able to target the features introduced in XFA 3.0 (Acrobat/Reader 9.1).  If you need a refresher on exactly what features this includes, your can search for "XFA 3.0" on this blog and you will find them described in some entries back in April 2009.

Perhaps more importantly, this is the version of Designer where we introduced the experimental macro feature — first described here.

In order to target the new XFA features introduced in Acrobat X (XFA 3.3) you will have to wait for a new version of Designer to be released with LiveCycle.

Now on to the new features added to XFA 3.3 / Acrobat X.

Flash in XFA

Probably the most exciting new capability in this release is the ability to embed flash objects in an XFA template.  This means your interactive forms may now share their data with charts.  You can embed instructional video. You can introduce a slider widget. A new pop-up widget selector dialog. Have fun. 

Implementation

Surprisingly, we did not introduce any new markup to support embedded flash objects.  We resurected a part of the grammar that was not in active use: the exObject element. Flash content will be defined in the context of a host field where the ui element is an exObject e.g.:

<field>
  <ui>
    <exObject classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" 
              codeType="application/x-shockwave-flash" 
              archive="<uri reference to primary SWF resource>"/>
  </ui>
</field>
            

The rest of the parameters (flashvars, playcount, speed, embedded/windowed, poster, etc.) will be defined as content below the exObject element.

The host field will determine the size and positioning of the flash object (when it’s not displayed in a floating window).

If you are embedding flash in PDF today, you save data/state using ExternalInterface:

ExternalInterface.call("multimedia_saveSettingsString", "save to data or formstate");
state = ExternalInterface.call( "multimedia_loadSettingsString" );
            

For SWFs that are embedded in an XFA form, these calls will save/load the host field data – which will be persisted in the XML form data or form state when the field is not bound.

The XFA object model has 3 new methods:

field.ui.exObject.setState(state) // state is either "activate" or "deactivate"

field.ui.exObject.getState();

// call an Actionscript method exposed via ExternalInterface
field.ui.exObject.invoke(methodName, arguments);

ActionScript can call into form JavaScript in this form:

ExternalInterface.call("foo.bar", "parameter 1 data", "parameter 2 data");

This will call the bar() method in the script object "foo" and pass in the two provided parameters.

There are many more details you will want to know about eventually, but these are the basics.

RTL Subforms

In order to provide better support for right-to-left languages (Arabic, Hebrew), subforms may now flow in a right-to-left direction.  In addition, subforms and exclusion groups may now also specify a horizontal alignment so that content rendered top-to-bottom can be aligned on the right hand side of the parent subform.

Implementation

The new grammar to support RTL functionality is on the subform element:

<subform layout="position | tb | lr-tb | rl-tb | table | row | rl-row" 
     colSpan="1" columnWidths="..." 
     hAlign="left | right | center | justify | justifyAll" >
    ...
</subform>
            

Bulleted and Numbered Lists

The subset of xhtml markup supported in the XFA grammar has been expanded to include the <ol>, <ul> and <li> elements.

XML Encryption

There are now options to leverage the W3C XML encryption standard (http://www.w3.org/TR/xmlenc-core/) with the form data.  The form author can choose to encrypt fragments of data or the entire data set.

Forms that submit XML data can encrypt their data before submission so that it is secure until decrypted by the recipient. 

Implementation

Encryption is managed by a new <encryptData> element that can appear below the <event> and <submit> elements. 

Restrict Console

There are new viewer preferences that will disable the console and JavaScript debugger for specific forms.  There is new configuration grammar that will set these viewer preferences when a PDF is generated from an XFA definition.

Deprecate Legacy Rendering

Ok, this is not an enhancement, but something you ought to be aware of.  Forms that are authored with a target version of XFA 3.3 can no longer be rendered with legacy rendering.  Legacy rendering will continue to be supported for all previous versions.

Legacy rendering was used to bridge the transition of XFA 2.5 (Acrobat
7, 8) documents forward. Having extended the bridge to Acrobat 8.1, 9.0,
9.1 and 9.2 it is no longer needed for Acrobat 10.

Version Correlation

In case you needed a score card, here is the history of XFA and Acrobat/Reader versions:

XFA Version Acrobat/Reader
2.1 6.02
2.2 7.0
2.3 7.0.1, 7.02
2.4 7.0.5, 7.0.7
2.5 8.0
2.6 8.1, 8.1.1
2.8 9.0
3.0 9.1, 9.2, 9.3
3.3 10.0

 

18 Responses to Acrobat X and XFA 3.3

  1. Great set of new features, I can’t wait. Will be interesting to see whether Avoka SmartForm Composer or Adobe Designer has XFA 3.3 support first!

    With the new XML encryption feature (which is great, as we have a lot of clients that would like this) will there be support with LC Forms encrypt/decrypt the XML data?

    regards Malcolm Edgar

  2. radzmar says:

    Hi,

    interesting news.
    I’m wondering if there will be an oportunity to embed also SVG’s in the future?!
    This would be cool as you use graphics (company logos, technical illustrations etc.) without that resolution and file size problems you currently run into when using the image fields.
    SVG is XML-based like XFA forms, so this seems natural.

    • Radzmar:
      Embedding SVG is an enhancement that has been given strong consideration in the past.
      I agree that it would be a natural fit and would address some important use-cases.
      But I can’t say whether it will eventually get implemented or not.

      John

      • radzmar says:

        Thanks John,

        that was what i was afraid of.

        Off topic:
        Just another thing, regarding your “Shared Data in Packages Pt.2” (Sorry to bother you).
        You closed comments for this thread, so I wasn’t able to ask you a question there.
        I’m really impressed about this sample, and like to use this, but I ran into a problem.
        The embedded forms get prepoplated when opening and can also update the package form, but the embedded forms doesn’t get updated when changing things in the package form.

        • John Brinkman says:

          Radzmar:
          Hmm. I didn’t intend to close comments on the packaging entries. I’ve fixed it.
          As for the specific issue, the embedded forms get updated from the package form only if they are open. You could implement the solution such that all embedded forms get updated from the package (whether open or not), but that would require each of them to be opened and saved. This won’t scale for PDFs with many embedded forms. And since the aggregate of all the data is stored in the package, it shouldn’t matter whether the embedded PDFs are up-to-date.
          John

          • radzmar says:

            Well, the problem I described occurs with the attached file opened.
            The data is synchronized, but only when opening not when changing any data in the package form.
            Vice versa it works.
            The thing that makes me puzzled is that there is no error in the console. :-/ (musing)

  3. John Brinkman says:

    Radzmar:
    I just re-downloaded the sample and tried it again — it seems to behave correctly for me.
    You might want to double-check that:
    – Make sure you exit the field in the attachment form
    – set focus to the package doc
    Other than that, I’m stumped.

    John

  4. Stefano says:

    I can’t wait!!!!
    This is so COOL !

  5. scott says:

    Hi John,

    it’s great to hear that you can embed a flash object into a livecycle form. Are there currently any other ways to embed a sound file into livecycle pdfs, either in earlier versions or designer 9.0?

    • John Brinkman says:

      Scott:
      In Acrobat/Reader 9.0 form you could embed a regular PDF attachment that had multi-media (sound). It’s just a bit awkward to open the attachment and play the media.

      John

  6. scott says:

    I have a pdf that was created in the new Livecycle ES2 (version 9 which came with Acrobat X) and we now have a mysterious bug or at least think it’s a bug. Where is a good place to report this bug?

    Basically, our PDF which we populate on our website using coldfusion is then displayed in the browser. The problem is that now the SAVE Icon no longer will display the SAVE dialog box. But If we take that same PDF and save it to the hard drive and open it up in a browser, then the Save dialog box does display ok. is this a security issue perhaps?

  7. Wes Freeman says:

    That’s great that the bulleted and numbered lists are supported in xhtml now. I spent some time figuring out how to do that yesterday–still can’t assume everyone has X, but at least we’ll be able to in the future! In order to get bullets in 9, I used the unicode character • (& #x2022;) along with tabs for spacing.

  8. Max Wyss says:

    Two questions:

    • Which version of Acrobat/Reader can handle XFA 3.3? 10? how far back?

    • Where is LCD on Mac? Only if that were available, the statement “As usual, LiveCycle Designer is bundled with Acrobat Pro.” would be true.

    Thanks.

    • John Brinkman says:

      Max:
      1. Only Acrobat/Reader 10 can handle xfa 3.3. None of the earlier Acrobat/Reader versions can handle 3.3.
      2. LCD remains a windows-only product. I suppose I should have more accurately stated: “bundled with Acrobat Pro for windows”.

      John

      • Max Wyss says:

        Thanks for the explanations, John.

        Can I assume that the fact that Acrobat/Reader 10 is required for XFA 3.3 is communicated sufficiently to the forms developer?

        Not having access to LCD (as being Mac-based), which XFA versions can the forms developer chose in the newest incarnation? (3.3 is clear, but which ones in addition)?

        Another question came up… is there a business case for suppressing Console access?

        Thanks once more.

        Max.

        • John Brinkman says:

          Max:
          Adobe Designer gives guidance to the author for the correct version. In the Form Properties menu under the “defaults” tab, you choose the target version for the form.
          If you choose Acrobat 9, designer creates an XFA 2.8 template.
          If you choose Acrobat 9.1, designer creates an XFA 3.0 template.
          etc.
          The target versions that are available in the Designer shipping with Acrobat X Pro (for windows), are: 7.05, 8.0, 81, 9.0, 9.1.
          As I mentioned in the blog post, you will not be able to target 10.0 until the next version of designer that ships with LiveCycle. (and I expect in that release the 7.05 option will no longer be available)

          The business case for restricting console access is that customers asked for it :-) There are some customers uncomfortable with allowing arbitrary JavaScript to be executed against their forms from the console.

          John