It’s been a few years now since XFA appeared on the scene in Acrobat 6.04 and this whole XFA/AcroForms thing is still a constant problem. For example, it’s rare that forum posts will mention what technology the poster is using, which leads to the inevitable bad answer, or a whole thread of “what tool did you use to build your form?” New users don’t know (or care)there are two forms technologies because Acrobat quietly guides them into making XFA forms. And, it seems that more experienced users are confused about the programming differences. Adobe doesn’t seem to have spent much time making these things clear. From an Acrobat user perspective, it kinda seems like they’re pretending AcroForms don’t exist.
Well, I deal with PDF programming issues. For programming, the differences in the technologies are vast. In order for me to provide good information to my clients and to answer questions on the forums, it’s very, very important these differences are understood. So, I’m going to try to set the record straight here.
First, AcroForms is the PDF forms technology. It was built into the PDF specification way back in Acrobat 3.01. It was designed to be an integral part of PDF, i.e., to fit neatly and cleanly into what PDF is. Ok, so what is PDF? PDF is a high fidelity, finished, self contained, presentation format. This is really important to understanding AcroForms. PDF is a heavy format. Not necessarily in terms of bytes, but in terms of rendering. Rendering a PDF involves complex vector graphics, color spaces, and fonts. The basic content of a PDF is static. It doesn’t quickly move and change. It’s meant for things like manuals, archived documents, reports , anything that’s printed, used off line, stored, secured, passed around whole, etc.
Now, this is not to say that PDFs are static, they’re not. Just the background content is static. Dynamic, interactive features are handled by annotations. These are boxes that float over top of the PDF content. Really they are little windows. Each kind of annotation handles a different type of interactivity. There are markup annotations, multimedia player annotations, 3D annotations, link annotations, and of course. Form Field annotations. Form field annotations are the basis of the AcroForms forms technology.
Because AcroForms are an integral part of PDF, the AcroForms JavaScript model is an integral part of the Acrobat JavaScript model. There is no distinction in the JavaScript reference between these two things, i.e., the Acrobat JS model and the AcroForms JS model. They are one and the same.
This means that all Acrobat features can be used together. We can have a long PDF catalog with an order form built into it. We can use AcroForm form fields as controls on interactive 3D or Multimedia PDFs. Heck, we could have a long catalog with multimedia, 3D, and AcroForms all working together. There’s no limit to how native PDF features can be mixed and matched to build incredible interactive, self contained, and good looking (both print and screen) documents. Take a look at the brochures on this page, (http://www.bcpictures.com/) .You can even use PDF as a kind of Rapid Application development platform, building mini PDF apps. I’ve written quite a few of these (there are a couple here http://www.windjack.com/resources/howto.html).
So, AcroForms are great for PDF centered applications, in fact they are essential. PDF would be a flat static format without them. Let me say this again. AcroForms are absolutely necessary to the PDF and Acrobat technologies. There is no way around this, there is no substitute.
However, as a purely forms technology, AcroForms are a bit lacking. Ok, it doesn’t exactly suck, but AcroForms are a bit behind the times when it comes to whizzy dynamic forms. It ain’t XML. Which brings us to XFA, or LiveCycle forms, which are XML.
Let’s be clear, XFA is not PDF. It does not look, act, or smell like PDF. XFA forms are built in LiveCycle Designer, which is a completely separate tool from Acrobat. Even though Adobe puts them in the same box and tries to fool users into thinking they are making their forms in Acrobat/PDF, they are totally different animals. LiveCycle Designer creates XML forms using the XFA specification. The JavaScript model for XFA is also completely different than the AcroForms model. And I mean a completely different paradigm. Because XFA is XML, the form fields exist in a naturally hierachal system. Everything in XFA JavaScript revolves around this hierarchy, whereas AcroForms JavaScript treats the documents and form fields as a mostly flat, linear structure.
XFA is a forms only technology. It’s not for creating any other kind of electronic document. It’s a light and fluffy spec like HTML. It typically uses fonts common on most user’s systems. It uses simple graphics that can be drawn quickly, and it only recognizes the basic Device RGB color space. Because of these features, XFA forms can be dynamic, quickly reshaping themselves into new configurations. The XML format provides a boxes-in-boxes structure ideal for creating form elements that move and change as the user interacts with them.
One of the biggest conceptual differences between PDF and XFA is that in XFA, non-interactive drawn elements like static text and graphics are on the same level and treated the same as the form fields. Remember that in Acroforms the background is static, the interactive form fields float over top of an unchanging picture. In AcroForms, only the form fields can move and change. In XFA the static parts are mixed in with, and move and change with the interactive parts. This is an essential part of creating dynamic forms. For example, if I have an address field that can grow to accommodate a larger address, I need the elements underneath the address field to all move down together, including any static text.
This type of dynamic interaction is a not possible in AcroForms and it is a big advantage of XFA forms. Another advantage of XFA is that LiveCycle Designer is a pretty good form design tool. It’s got most the nice detailed features form designers want and that are lacking in Acrobat. This makes sense because XFA is a forms only technology, whereas Acrobat/PDF are designed for handling any kind of electronic document.
Ok, so now you’re scratching your head and wondering how they put this highly dynamic forms technology into a heavy duty document format. They punted. Let’s face it, XFA in PDF is a round peg in a square hole. They did it by completely subverting the PDF rendering engine in Acrobat. When a LiveCycle form is loaded into Acrobat, most of the regular PDF/JavaScript engine goes out to lunch and the XFA engine takes over. It’s practically a different application. You may have noticed that half the Acrobat toolbars go gray when an XFA is opened. That’s because most of the regular PDF features are incompatible with the nature of XFA. Not that you can’t get around some of these restrictions with creative JavaScript programming (you can), but if you add PDF features to an XFA form, they’ll be wiped out the next time you edit the form in LiveCycle Designer.
To summarize: XFA forms are great for the dynamic, form centric features and the separate forms design tool. As an aside, another great advantage I didn’t mention before is the Calendar popup. Everyone wishes this one was available in AcroForms. So if you’re designing/creating forms, and only forms, then it’s well worth your while to do it with an XFA form. This is the way to the future.
However, if you’re designing a document that has form features (such as navigation buttons), if you need a PDF feature like multimedia, bookmarks, 3D, high fidelity reproduction, etc. then you need to stick with regular PDF and AcroForms.
An end note: Adobe has been trying to get around this apparent conflict in technologies with the introduction of “Packages” in Acrobat 8. Packages allow documents of different types to be mixed together in the same PDF in a way that makes them look like the same document. Now this is a great compromise and I’m sure we’ll see more advances in this area so we can all get the advantages of both technologies without having to beat our heads against the wall so much, Ouch!
