Presence vs Relevance
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 |
| visible | in | in | |
| visible | in | out | |
| invisible | out | in (visible) | |
| invisible | out | out | |
| hidden | out | out | |
| 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 |
| visible | out | in | |
| visible | in | out | |
| invisible | out | in (invisible) | |
| invisible | in (invisible) | out | |
| hidden | out | in (hidden) | |
| 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) | visible | |
| Visible (Print Only) | 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.
September 30th, 2007 at 5:28 am
Stefan,
I have a problem that is related to this topic. I have a date field in an instantiated subform that has a script on the exit event that makes one of three sets of hidden buttons visible, depending on the date entered. Clicking on one of the buttons makes a third (text) field visible and adds “1″ to one of two numeric fields (for counting purposes). On that click event, it also changes the date field to access: “protected” and hides the buttons. Basically, after all these events, I don’t want any more changes.
The problem is with the protection of the date field. Although it does prevent any changes to the date, if the mouse clicks in the caption part of the date field (not the calendar field), it triggers the exit event and the buttons appear. The bigger problem is that if one of those buttons is clicked, it adds 1 to the numeric field and then the count is off. The script works perfectly as long as there is no clicking on the date field after all this above events happen. I thought that “protected” meant that no events would be triggered. Is there anyway around this?
Thank you!
October 11th, 2007 at 12:59 pm
Jane,
I would suggest you set the access property of your date/time field to “readOnly” instead of “protected”. This will make the field non-interactive and it will no longer respond to any mouse or keyboard events.
March 28th, 2008 at 5:18 pm
I am a beginner and do not know xml very well. I am creating a form where I want a border sunken box around the text field but when the form is printed I want the border to dissappear only showing the text that was entered into that field. Can this be done, and if so can you give me very simple steps on how to accomplish this. I am using LiveCycle Designer that is included with Adobe Acrobat 8.
April 4th, 2008 at 10:14 pm
Kyle,
I’m assuming that you mean your text field has a sunken border only around its content area (i.e. only around the value), not its nominal extent (i.e. its caption and value). To do this, you simply need to use the PrePrint and PostPrint to hide and show, respectively, the content area border of the field.
Select the text field and use the “Window > Script Editor” command to show the Script Editor palette. Choose the PrePrint event and hide the content area border (you may also have to set the language to JavaScript since I’m showing JavaScript in this example):
Next, choose the PostPrint event and make the border visible again:
That’s it!
April 17th, 2008 at 3:20 pm
I have a problem on trying to decrypt a owner password protected Adobe Form. The form is desiged on Adobe LiveCycle Designer 8.1.1 and is owner password protected. I have tried to use 2 Java open source software (iText and PDFBox) to decrypt without success. Any suggestions? In both open source software, I can detect the adobe document is encryted with their APIs.
April 19th, 2008 at 7:19 am
Tom Chung,
I’m afraid I can’t help you decrypt a password-protected PDF. It’s not something you should be trying to do…
June 5th, 2008 at 9:51 am
Hi Stefan,
I am getting this weird problem in LiveCycle (not that it operates smoothly on other occasions). I have a few text fields on the form which are hidden (there to hold user entered options across various sessions). There is a button whose click event updates the values of these fields. The problem is, even though in the click event, it shows the values (rawValue) of the text fields as being updated, these are not updated on the form itself. If I use app.alert() in click event to see values, these are shown as updated values but the values in the fields don’t change (I have checked this by making the fields visible so that I can spot the change). These remain null forever.
If you can help, I will greatly appreciate that. I have checked Adobe Forums to see if there is a related post but found none. The nearest I can find is yours and I am encouraged to see that you actually reply to the posts; on many sites, replies are found rarely (if ever).
Thank you in advance.
Rahul.
June 8th, 2008 at 2:19 pm
Rahul,
What’s the script you’re using in the button’s Click event to update the values of the hidden text fields? If your script is written in JavaScript, have you looked at the JavaScript Console in Acrobat to see if there are any errors?