LiveCycle Doc team

The LiveCycle Documentation Team would like to wish all of our readers a happy holiday! And best wishes in the new year!

Posted by Tasmina Patel at 3:41 PM | Permalink | Comments (0)

Dear Santa Claus,

How are you? The missus? And the reindeer? Great, great.

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.

I first got the idea after watching some Christmas movies with my kids. Your operation, in particular the manufacturing and distribution units, appeared to implement what can only be described as 18th century methods and processes. You gotta loosen up there big guy, accept change as a good thing and roll with the technology. Send the elves out on some training, it'd be good for them to upgrade their skills.

Anyway, I feel like LiveCycle ES could really help improve the efficiency and cost-effectiveness of your organization. First off, all that data collection must be a real challenge. Tracking the behavior of millions of children and cross-referencing against their previous track records, my head hurts just thinking about it. If it's one thing LiveCycle ES does, it's data collection. You could use PDF forms, form guides, Flex applications, whatever those little elves feel most comfortable using, and push all that beautiful electronic data into secure databases. Check out the screen shot below of data capture in action.

View larger image

Of course, data capture is likely only one aspect of the process. Data must get disseminated down to the various toy-producing groups, decisions must need to be made by middle management elves, etc, etc, etc. LiveCycle ES does that too. Using process designs, you can craft workflows visually while at the same time having access to some very powerful application building technology. I've attached a picture of a process I think you could use for the receipt and review of incoming letters (like this one you are currently reading).

View larger image

Behind it all, LiveCycle ES has some great server-side services that do just about everything (but clean up reindeer droppings). There are services for protecting documents, assembling and generating PDFs, encrypting, accessing databases, email ... the list goes on.

Just think how great a few LiveCycle ES solutions could be. Improved efficiency means more time for yourself. You'd be able to get some exercise so you can lower your chances of heart disease. Your weight is becoming an issue according to 9/10 doctor's I’ve surveyed (and by "doctor" I mean "people playing World of Warcraft"). Or perhaps you and the missus can reconnect on a beach somewhere without all those prying, elvish eyes (little scamps).

Maybe you'd save so much money by replacing some of those antiquated methods you currently use that you could look at investing in some innovative research. For example, maybe expand your web presence from nothing to something, or maybe replace those reindeer with something that generates a little less fertilizer.

Hey, it's all up to you big guy, I'm just the messenger. But give LiveCycle ES a look, it might just help your organization get a little better.

Yours truly,
Alex

P.S. Oh, and while I have you, there is one thing I wanted to ask for this year on behalf of myself and my family. A little world peace would really go a long way right about now. Aaannnnnd maybe an iPhone.

Posted by Alex Mitchell at 10:21 AM | Permalink | Comments (0)

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.

PDF Packages (Acrobat 8)

The PDF Reference, sixth edition, version 1.7 (Acrobat 8) introduced the collection dictionary, which specifies how a viewer application’s user interface presents collections of file attachments. Acrobat 8 uses the term PDF Package to describe a PDF document that contains a collection dictionary.

The files in a PDF Package can be in different formats and created in different applications. For example, suppose you have a project that includes PDF documents, text documents, email messages, spreadsheets, CAD drawings, and Microsoft® PowerPoint presentations. You could combine these documents into a PDF Package. The original files retain their individual identities but are still part of the one PDF Package file. Each component file can be opened, read, edited, and formatted independently of the other component files in the PDF Package if the corresponding application is installed.

A PDF Package is actually a PDF document (the cover sheet) that has attachments (the component files), but with added information used to organize the component documents (for example, date, author, or topic). When creating a PDF Package, you can provide a cover sheet or allow Acrobat to provide a cover sheet for you.

PDF Portfolios (Acrobat 9)

ISO 32000-1:2008 - Document management -- Portable document format (Acrobat 9.0) extended the collection dictionary with attributes that specify a customizable ActionScript® user interface for navigating the files in the collection. It also extends the collection dictionary with attributes that specify a folder structure for the files in the collection.

The user interface for a PDF Portfolio includes the following parts:

• Compiled ActionScript program (This program cannot be based on Adobe AIR™.)
• (Optional) Resources used by the program, including graphics and localized strings
• (Optional) Icon that provides a visual clue about the appearance of the layout
• (Optional) XML file that identifies the interface and organizes the parts of the PDF Portfolio Layout. This format is specified in the Acrobat Navigator File Format. To gain access to this specification, you must submit a form to Adobe, as described at http://www.adobe.com/devnet/acrobat.

The ActionScript program invokes methods exposed by Acrobat to present a user interface for browsing the documents contained in the PDF Package. The ActionScript program can also invoke methods provided in other ActionScript libraries. The program, resources, and XML file are compressed (using WinZip or a similar program) to produce a PDF Portfolio Layout. (Developers informally use the term PDF portfolio navigator to mean a PDF Portfolio Layout.) Placing the resulting PDF Portfolio Layout in the Acrobat application data directory makes it available to Acrobat users.

Using Acrobat Pro 9 or Acrobat Pro Extended 9, users can create a PDF Portfolio that includes a custom PDF Portfolio Layout or one of the sample PDF Portfolio Layouts installed with Acrobat. The result is a PDF Portfolio that contains its own user interface. Adobe Reader 9 and Acrobat Standard can display the PDF Portfolio Layouts included in PDF Portfolios, but they cannot create PDF Portfolios.

Acrobat 9.0 uses the term PDF Portfolio to describe any document that contains a collection dictionary, regardless of whether the file includes its own user interface for navigating files.

Acrobat behavior relative to PDF Packages and PDF Portfolios

Here is a clarification regarding Adobe Reader and Acrobat behavior relative to PDF Packages and PDF Portfolios. In this context, there is no difference between PDF Packages and PDF Portfolios.

• Adobe Reader 8 and Acrobat 8 use a standard user interface to display the documents in the collection and ignore the PDF Portfolio Layout (if present).
• Adobe Reader 9 and Acrobat 9 use a PDF Portfolio Layout to display the documents in the collection. The contents of the PDF Portfolio determines the source of the layout used.


PDF Portfolio that includes a PDF Portfolio Layout: Adobe Reader and Acrobat use the provided PDF Portfolio Layout to display the documents in the collection

PDF Portfolio that omits a PDF Portfolio Layout: Adobe Reader and Acrobat use a default PDF Portfolio Layout to display the documents in the collection.

In the following situations, Acrobat 9 displays the collection files using an interface similar to the one used in Acrobat 8:

• Acrobat 9 is installed in locales that use a right-to-left writing style.
• Acrobat 9 preferences for Accessibility and International restrict support for the PDF Portfolio Layout (if provided).

For more information

For information about creating a custom PDF Portfolio Layout, see the Documentation tab of the Acrobat Developer Center.

Posted by Kathy Stone at 11:20 AM | Permalink | Comments (0)

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.

Objects available in the Standard tab of the Object Library palette that are based on the same base XML object definition share a set of common properties and methods. If you are referring to the LiveCycle Designer ES Scripting Reference, you determine the set of properties and methods available based on the corresponding base XML object. Similarly, each base XML object definition contains a child object that specifically controls the visual appearance of the LiveCycle Designer ES object.

For example, if you want to browse the properties and methods that are available for a Date/Time Field object in LiveCycle Designer ES, you would start with the field object. If you want to browse the corresponding XML object that controls the visual appearance of the Date/Time Field, view the dateTimeEdit object.

The table below illustrates the mapping between objects that you see in the Standard tab of the Object Library palette in LiveCycle Designer ES, and the corresponding XML Form Architecture object.

Standard Object Library Object	XML Form Architecture Object (Base)	XML Form Architecture Object (UI)
Barcodes	field	barcode
Button	field	button
Check Box	field	checkButton
Date/Time Field	field	dateTimeEdit
Decimal Field	field	numericEdit
Signature Field	field	signature
Drop-Down List	field	choiceList
Email Submit Button	field	button
HTTP Submit Button	field	button
Image Field	field	imageEdit
List Box	field	choiceList
Numeric Field	field	numericEdit
Paper Forms Barcode	field	barcode
Password Field	field	passwordEdit
Print Button	field	button
Radio Button	field	checkButton
Reset Button	field	button
Subform	subform	N/a
Table (including body rows, header rows, and footer rows)	subform	N/a
Text Field	field	textEdit

For more information on using objects in LiveCycle Designer ES, as well as creating calculations and scripts, see LiveCycle Designer ES Help.

Posted by Alex Mitchell at 11:00 AM | Permalink | Comments (0)

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.

1. (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.


2. Assemble the PDF Portfolio.


3. (Optional) Encrypt or policy protect the PDF Portfolio.


4. Certify the PDF Portfolio.


5. 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:

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
    <PDF result="outDoc" >
        <PDF source="_AdobeCoverSheet" bookmarkTitle="Cover"/>
        <PackageFiles source="doc1" required="false">
            <File filename="MyFirstFile.pdf" mimetype="application/pdf"/>
        </PackageFiles>
        <PackageFiles source="doc2" required="false">
            <File filename="MySecondFile.txt" mimetype="text/plain"/>
        </PackageFiles>
    </PDF>
</DDX>

Any of the following changes would compromise a certified PDF Portfolio:

• Component files are modified
• Component files are filled in, even if the component file's certification allows form fill-in
• Cover page is modified, unless the certificate allows form fill-in

Information about all of the DDX elements that are discussed in this posting can be found in DDX Reference.

Posted by Kathy Stone at 6:32 PM | Permalink | Comments (0)