Listen, unlike previous years when I provided you a detailed, alphabetical breakdown of the goodies I’d like to receive, this year I’ve decided to take a different approach. This year I’d like to get you something: Adobe LiveCycle ES. And when I say “get you something”, I mean you should get it for yourself.

This article is included in the LiveCycle Documentation blog because it establishes a foundation that will make it easier to understand LiveCycle features related to PDF Packages and PDF Portfolios.

In 2006, the PDF specification added support for document collections, which provide information that PDF viewing applications can use for navigating the files attached to a PDF document. Since then, Adobe® Reader® and Adobe Acrobat® have used the terms PDF Packages and PDF Portfolios to describe these collections. This article explains the history of these terms, and it describes the Acrobat user interface that makes PDF Packages and PDF Portfolios so dynamic.

When you create calculations and scripts in LiveCycle Designer ES, you should be aware that the objects on which you are adding scripts are actually defined as XML objects in the underlying XML Forms Architecture. That means while the Standard tab of the Object Library palette contains a wide variety of objects, many of those objects are defined by the same XML object. As a result, the various scripting properties and methods that are available are based on the definition of the XML object, and not the object in the Object Library palette.

With Adobe LiveCycle ES, you can certify PDF Portfolios to ensure that none of the documents contained within the portfolios are changed without being detected. Additionally, you can encrypt or policy protect PDF Portfolios and the files they contain, and you can apply usage rights to PDF Portfolios.

This article discusses limitations in the types of files you can include in certified PDF Portfolio and the order in which you must apply LiveCycle ES services when creating certified PFD Portfolios.

For definitions of the terms used in this article, see PDF Packages vs. PDF Portfolios located in the LiveCycle Doc Team blog (this blog).

The cover sheet in a certified PDF Portfolio can be an interactive form; however, the files contained in the portfolio must not be interactive. The certification for a PDF Portfolio becomes compromised if any of the component files are modified, even if the component file’s certification allows form fill-in.

To create a certified PDF Portfolio, apply operations in the following order. These services must be invoked within a short-lived process.

(Optional) For each document to be contained in the PDF Portfolio, encrypt or policy protect, and then certify. The files in the PDF Portfolio cannot be interactive forms, so you must not apply Usage Rights.

Assemble the PDF Portfolio.

(Optional) Encrypt or policy protect the PDF Portfolio.

Certify the PDF Portfolio.

Apply Usage Rights to the PDF Portfolio.

You can also create a process that consumes component files that are already encrypted, policy-protected, or certified. In this case, the order for applying services is still the same as above with the omission of the first step. If any of the component files consumed by your process are encrypted or policy-protected, ensure your DDX file defines them in a way that avoids the Assembler service having to open them. You can accomplish this goal by defining the component files using the <PackageFiles> source element, not the <PackageFiles> filter element. For example, the following DDX produces a PDF Portfolio without requiring Assembler ES to open the component files: