Designer 7.1 introduced the ability to specify whether a button was visible only on the (computer) screen, only on paper (print) or both (visible all the time). This feature, supported in conjunction with Acrobat 7.0.5, was then extended to all XFA objects (text fields, check boxes, lists, etc.) in Designer/Acrobat 8.0.

Unfortunately, how the two concepts interact is something that isn’t easy to grasp at first and so I thought I would delve into the details and attempt to clarify things.

Note that in this article when I write about Acrobat I include Reader as well.

Before Relevance

Prior to the concept of relevance, an object was either visible, invisible or hidden, as specified by the presence attribute and it didn’t matter whether the form as being rendered on a computer screen or printed on a piece of paper — it could either be seen or not.

One of the problems with this approach to presence surfaced when you wanted to design a form that had a submit button for the electronic “fill & submit” workflow but you also wanted to support the manual “fill, print & mail” workflow. When the user printed the form, they would get this submit button on the print-out which was completely useless and looked out-of-place.

In Designer/Acrobat 7.0 or earlier, if you wanted to prevent the button from printing, you had to resort to scripting the button’s PrePrint and PostPrint events in order to hide the button while the form was being printed:

PrePrint

this.presence = "invisible"; // or "hidden";

PostPrint

this.presence = "visible";

Relevance in Designer 7.1 / Acrobat 7.0.5 – 7.0.9

The advent of Designer 7.1 and Acrobat 7.0.5 introduced support for “relevance” on button objects only. Relevance lets us further define the circumstances where an object is visible.

There are currently two supported “views” to which objects may be relevant: Screen View and Print View. They are both straight-forward: The Screen View represents the form as it is seen on a computer screen (in Acrobat or a browser) and the Print View represents the form as it is seen on paper (after being printed).

The following table illustrates the view(s) in which a form object is visible given values assigned to an object’s presence and relevant properties. For instance, if an object is defined as follows in XFA

<field presence="invisible" relevant="+print">...</field>

it would be included (“in”) only in the Print View.

Relevant	Presence	Screen View	Print View
+print	visible	in	in
-print	visible	in	out
+print	invisible	out	in (visible)
-print	invisible	out	out
+print	hidden	out	out
-print	hidden	out	out

Note that if the relevant property isn’t specified, the presence property controls the object’s inclusion in both views at the same time (as was the case before the introduction of the “relevant” property).

More importantly, notice how setting the presence property to “invisible” and the relevant property to “+print” actually causes the object to be visible in the Print View (rather than invisible). This wasn’t the original intent and was corrected in Acrobat 8.0+.

Relevance in Designer/Acrobat 8.0+

The 8.0 versions not only added support for presense and relevance on all objects (text fields, list boxes, circles, squares, text, subforms, radio button lists, etc.) but they also corrected the results of some presence and relevant property combinations such that the two are now disjoint: The relevant property determines the view (Screen and/or Print) to which an object belongs and the presence property then controls the object’s visibility within that view.

The result is as follows (note the differences highlighted in blue between both tables):

Relevant	Presence	Screen View	Print View
+print	visible	out	in
-print	visible	in	out
+print	invisible	out	in (invisible)
-print	invisible	in (invisible)	out
+print	hidden	out	in (hidden)
-print	hidden	in (hidden)	out

As in previous versions, the omission of the relevant property gives control to the presence property in both views.

Setting Presence and Relevance in Designer 8.0+

Designer exposes presence and relevance via its presence property in the Object palette. It combines the two into the following settings:

Designer	XFA Relevant	XFA Presence
Visible	<not specified>	visible
Visible (Screen Only)	-print	visible
Visible (Print Only)	+print	visible
Invisible	<not specified>	invisible
Hidden	<not specified>	hidden

Differing Behaviors Across Acrobat Versions

Remember that the results of the relevant and presence property combinations are specific to the version of Acrobat being used to view/print the form.

For example, if you designed a form with a button that had

presence="invisible", relevant="+print"

it would be excluded from the Screen View but visible in the Print View in Acrobat 7.0.5 – 7.0.9. However, if you were to open the same PDF form in Acrobat 8.0+, the button would be invisible in the Print View.

---

Posted by Stefan Cameron on September 27th, 2007
Filed under Acrobat,Designer,XFA

---

A common need in forms is to ask the user to choose between a set of options within a list, be it a radio button list, list box or drop down list. What’s more is that these lists often include an “other” option to let the user specify something more specific that isn’t included in the list. The trouble is, how do you ensure that the user fills-in the “other” field prior to submitting their form?

I thought it might be useful to provide a sample form which demonstrates how to build a list field which has an “other” option and clicking on the “other” option displays a field for entering the specific value and makes that field required — but only if the user chooses the “other” option. (You wouldn’t want the “other” field to be hidden and required or else the user would never be able to submit their form since Acrobat would prevent the submission on the premise that there’s an un-filled required field somewhere.)

“Other” Fields in Acrobat/Reader 8.1+

The first thing I did was create my sample form using Designer 8.1 and Acrobat 8.1. That was very easy and just as straight-forward as I expected it would be: One radio button list, one list box and one drop down list, each set to be required and with their own “other” item and script to show their respective “other” field (and make it mandatory) when their “other” item is selected and hide it (and make it optional) when their “other” item is de-selected. Add a submit button and Acrobat/Reader 8.1 automatically takes care of preventing the submission if any required field isn’t filled.

To keep things simple, each list field has script that detects when the user either selects the “other” item or an alternate item and sets the presence and mandatory properties of its “other” field to be visible/required or invisible/optional, respectively.

Download 8.1 sample [pdf]

Minimum requirements: Designer 8.1, Acrobat/Reader 8.1

“Other” Fields in Acrobat/Reader 8.0 or Earlier

Unfortunately, I didn’t have the same kind of experience getting this form to work in Acrobat/Reader 8.0 or earlier.

The first thing I did, since my 8.1 sample form doesn’t use any functionality only available as of Designer/Acrobat 8.1 (in fact, it uses XFA properties and script functions that have been available since Designer/Acrobat 7 and likely even earlier), I simply used Designer 8.1 to set my form’s Target Version to Acrobat/Reader 7.0.5 and figured I would open it in Acrobat 7.0.9 and all would be good. Well, that wasn’t the case.

Aside from Acrobat not respecting the “required” setting on the radio button list (which was expected since required radio button lists weren’t supported until Acrobat 8.0), I discovered a very strange behaviour in the list box where simply having a statement within its Change event that sets a field’s mandatory property to “error” will always result in that field being required, as far as Acrobat/Reader is concerned, even if the statement doesn’t appear ever to be executed on form initialization. The result is that selecting an item other than the “other” item in the list box and attempting to submit the form prompts Acrobat to cancel the submission because a required field isn’t filled. The problem is that the required field is the list box’s “other” field which is hidden from view because it isn’t supposed to be required. Finally, there was also another issue with list boxes that have Change event script: Their value is never committed to the Data DOM, which means that the list box always appears to have no value and that also prevents the user from being able to submit the form because the list box appears never to have been filled (even though an item is clearly selected).

So the are three problems with the 8.1 sample form when it’s running in versions of Acrobat/Reader prior to 8.1:

1. Although properly supported in Acrobat/Reader 8.0, radio button lists can’t be set to “required”;
2. List boxes with Change event script containing a statement which sets a field’s mandatory property to “error” results in that field always being “required” (this strange issue is resolved in Acrobat/Reader 8.1); and
3. List boxes with Change event script don’t commit their value to the Data DOM (this is also resolved in Acrobat/Reader 8.1).

Fortunately, issues #2 and #3 can be resolved fairly easily simply by not using the Change event. The only viable alternative I found was using the Exit event instead. (Note that in the Exit event, you have to use the list’s “rawValue” property to determine its value rather than using the “xfa.event.newText” property as in the original Change event script.)

Issue #1 (required radio button lists not supported) can also be resolved although it requires a little more work. One alternative is to use the “Two Button Submit” Technique I described on a previous post on Complex Validations, which is what I implemented in my 7.x sample form.

Download 7.x sample [pdf]

Minimum requirements: Designer 7.0, Acrobat/Reader 7.0

---

Posted by Stefan Cameron on August 7th, 2007
Filed under Acrobat,Bugs,Events,Scripting,Tutorials

---

I was just notified that the XFA 2.5 specification has been posted to the Adobe LiveCycle Developer Center. For many of you, this is the end of a very long wait, I’m sure. Hopefully it contains all the information you’ve been looking for.

XFA 2.5 is supported by Designer 8.0 and Acrobat/Reader 8.0.

---

Posted by Stefan Cameron on June 19th, 2007
Filed under Acrobat,Designer,XFA

---

Since I posted about the new Acrobat/Reader 8.1 Update, I’ve had a few inquires about whether this also updates Designer. In fact, one of my readers recently pointed-out the fact that I was mistaken in thinking that the Acrobat update wasn’t also updating Designer. I’m glad some of you on top of this — sometimes there are just too many things to keep track of. 😉

The fact is that Designer does, in fact, get updated but only if you’re installing the Acrobat Pro 8.1 update since that’s the only way you can get the retail version of Designer 8.0. This means that if you have both Reader 8.0 and Acrobat Pro 8.0 installed on the same machine and you install only the Reader 8.1 update, Designer will not be updated (hence my mistake in thinking Designer wouldn’t get updated in any scenario).

As you can see here,

Designer gets a minor update to version 8.05 when you install the Acrobat Pro 8.1 update. This update to Designer contains only major bug fixes and not any new functionality (i.e. you won’t get any of the new LC Designer ES, a.k.a. version 8.1, features like Form Fragments and the Guide Builder Tool).

To get LC Designer ES, you’ll have to purchase an upgrade later this Summer for a small fee (same deal as when Designer 7.1 was released a couple of years ago). That’s because LC Designer ES introduces significant changes and a host of brand new, powerful features.

I apologize to those whom I led astray about the Designer 8.05 update.

---

Posted by Stefan Cameron on June 14th, 2007
Filed under Acrobat,Designer

---

Description

When changing a table’s column widths via the table object’s “columnWidths” attribute, the table’s columns will not be rendered correctly.

For example, consider the following table:

Clicking on the “Expand Columns” button sets the width of the first column to 2 inches and the width of the second column to 3 inches with the following script:

Table1.columnWidths = "2in 3in";

In Acrobat 8.0 or earlier, this is the result:

The problem is that the table’s layout hasn’t been properly updated after the changes to its column width attribute.

Workaround

Fortunately, there’s a simple workaround to this problem which consists in forcing an update to the layout after setting the column widths of a table:

Table1.columnWidths = "2in 3in";
xfa.layout.relayout();

Note that a lot of these table rendering issues have now been addressed in Acrobat/Reader 8.1.

When using the above workaround or Acrobat/Reader 8.1, this is the result you get:

Fix

Please refer to the Bug List for updated information on the version(s) affected by this bug as well as if and when it was/will be fixed.

---

Posted by Stefan Cameron on June 13th, 2007
Filed under Acrobat,Bugs

---