This is something many of you have asked me about in the past and I never had a definite answer. The only method I knew of was to use a print button from the Object Library palette and add some checks for invalid data (or unfilled fields) inside its click event which is set to call xfa.host.print() by default. The problem with this method is that the user could still print using Acrobat’s print command (either via “File > Print”, the print button in the toolbar or by using “Ctrl + P”).
I didn’t know any better because, well, prior to Acrobat 8, there wasn’t really anything better and the reason was that form validations simply weren’t triggered prior to Acrobat receiving the command to print. So while you could easily prevent a form from being submitted electronically if validations failed, there was no definitive way to prevent it from being printed… until Acrobat 8 and XFA 2.5 came along, that is.
Advanced Tutorial: Before you read further, I should warn you that this is an advanced tutorial as it (unfortunately) requires editing the “XML Source” using Designer since Designer doesn’t have settings for this yet.
New Validate element in the Config DOM
In version 2.5, the Present element in XFA’s Configuration Document Object Model (“Config DOM” for short), which houses configuration options for XFA applications (such as Acrobat and Reader), was extended to have a Validate element.
This element can have any of four optional values, each separated by a space: “prePrint“, “preSubmit”, “preSave” and “preExecute”. By default, the element is not specified and the default behaviour (which is the same when the element is specified but contains no values) is to validate prior to submitting the form only. Once values are specified, then validations are run only prior to the specified events.
For example, if you wanted to have a form that prevents the user from printing but not submitting when a mandatory field is empty, you would specify the following validate element in the Config DOM (the ellipsis mean there’s other stuff in there; what’s important is the validate element inside the present element):
<config>
...
<present>
...
<validate>prePrint</validate>
...
</present>
...
</config>
Unfortunately, this isn’t something that you can reliably set via script since these options are typically read-in on load and aren’t read again. Furthermore, Designer does not yet support setting the values in the validate element. In order to set this option, you’ll need to edit the XML Source in Designer and find the following markup about 2/3 way down:
<config xmlns="http://www.xfa.org/schema/xci/1.0/">
<agent name="designer">
...
</agent>
<present>
<!-- [0..n] -->
...
Once you’ve located the <present> element inside the <config> element (the Config DOM), you’ll need to insert the <validate> element:
<config xmlns="http://www.xfa.org/schema/xci/1.0/">
<agent name="designer">
...
</agent>
<present>
<!-- [0..n] -->
<validate>prePrint</validate>
...
(Notice the <validate>prePrint</validate> element above.)
When you’re done making the change, click on the Design View tab and make sure you say “yes” to have your changes applied.
XFA 2.8/Acrobat 9 Update: With the release of XFA 2.8 and Acrobat/Reader 9.0, the <validate> element is now located under the <acrobat> element in the Config DOM:
<config>
...
<acrobat>
...
<validate>prePrint</validate>
...
</acrobat>
...
</config>
To ensure backward compatibility, if the <validate> element is not found under <acrobat>, Acrobat/Reader will fall back to looking inside the old <present> to see if it’s defined there.
Now you’re probably wondering what the different values mean so here’s a quick explanation:
- prePrint: Failed validations prevent the form from printing.
- preSubmit: Failed validations prevent the form from being submitted electronically.
- preSave: Failed validations will not prevent the form from being saved however Acrobat/Reader will issue a special warning message, after issuing the validation error message, to inform the user that the validations failed. I’m guessing this is because the user may be saving the form to continue filling it at a later time so the save can’t be completely prevented.
- preExecute: Failed validations will prevent the form from executing a data connection (usually to a web service).
In all cases, any validation error messages will be displayed and this should work in Reader 8 as well. If you have set validation warnings (as opposed to errors), then the warnings will be displayed but the user’s action will not be stopped.
Sample Form
I took the time to put together a little sample form which demonstrates a Dynamic PDF form that cannot be printed nor submitted in Acrobat/Reader 8 and above unless the text field is filled.
Download Sample [pdf]
Minimum Requirements: Acrobat/Reader 8 or above.
Updated: December 20, 2008
Posted by Stefan Cameron on April 13th, 2008
Filed under
Acrobat,
Designer,
Tutorials
