Posts in Category "Designer"

Merging Text Objects

Here are two really convenient features I thought I should highlight since it can really save you time, especially if you’re cleaning-up a form after importing it as "editable objects" or "flowable layout" (which usually produces dozens, if not hundreds of small text and field).

Since Designer 7.1, there are features available to you which are capable of merging text objects with other text objects or fields.

Merge Selected Text Objects

If you select multiple text objects, you’ll get a command in the context menu and in the top-level Layout menu which reads, "Merge Selected Text Objects". If you select it, all the selected text objects will be combined into one. This is useful if you have multiple text objects each pertaining to a specific sentence which you’d like to combine into a single text object:

Before the merge:

After the merge:

Notice that all formatting is retained and that the order of the sentences depends on the original location of the various text objects with respect to each other, not the order in which they were selected.

Merge As Caption

This feature makes it really easy to set a text object as a field’s caption when that field does not have a caption. When you select a single text object along with a single field which doesn’t have a caption, you’ll get a "Merge As Caption" command in the context menu as well as in the top-level Layout menu. When you select this command, the text object will become the field’s caption, retaining all original formatting:

Before the merge:

After the merge:

As with the "Merge Selected Text Objects" feature, the placement of the resulting caption depends on the location of the text object with respect to the captionless field. Here’s an example where the text object is located below the field:

Before the merge:

After the merge:

Better Form Design with XFA 2.5

You may have noticed that the new version of Designer and Acrobat that Adobe recently released uses a new version of XFA (2.5 to be exact). While the language has many new features in and of its own, the version of the language (2.5 vs 2.4 or older) also dictates how your forms will behave in Acrobat 8+ with respect to certification (digital signatures) and ubiquitization (Reader-enablement).


Since this new behaviour, which is geared to encourage better form design going forward, will ultimately change the way you write certain scripts, I believe it’s important to start with some basic knowledge of XFA forms, see what happens when they get certified/ubiquitized, examine how each used to behave in Acrobat 7 and then how they’ll behave in Acrobat 8+.

XFA Primer

Simply said, an XFA form is described inside an XDP file. When it’s saved as a PDF file, the XDP is actually embedded into the PDF so that it can be processed by Acrobat.

If you look at the XDP (via Designer’s XML Source view), you’ll see that it’s simply a collection of packets that describe the form’s various components. For example, <template> describes the form’s layout and behaviour while <sourceSet> contains a collection of data connection descriptions you’ve defined using the Data View palette. When the form is loaded as a PDF into Acrobat, each packet is loaded into its own in-memory (temporary) model and that’s what you actually reference in your scripts. For example, you access the sourceSet packet via the sourceSet model with "xfa.sourceSet". Changes to these models are reflected directly into their pertaining packets.

Form Certification/Ubiquitization

Without going into more details than are necessary, once a form is either certified and/or ubiquitized, modifications to any of the protected content (the various models) should be prevented. Modifying the form’s protected content post-certification/ubiquitization would invalidate the certification/ubiquitization status. Such modifications mean that the document is no longer in the state in which it was when it was digitally signed and therefore can no longer be trusted by the recipient as being authentic. Even though the modification may have been caused by authored script in the form, no distinction is made between those kinds of modifications and malicious attacks by an unknown party to, for instance, cause form data to be submitted to an alternate server.

Acrobat 7 and XFA 2.4

Acrobat 7 supported XFA forms up to XFA 2.4 (which Designer 7.1 would author). Once an XFA 2.4 form would be either certified and/or ubiquitized, Acrobat 7 would detect modifications to the form’s protected content and would invalidate its certification/ubiquitization status if such modifications occurred. It didn’t, however, prevent the sourceSet model from being modified post-certification/ubiquitization even though the <sourceSet> packet was included as part of the certification/ubiquitization process.

The inherent danger in this was that while any form that would do common things like display all the records in a database or select specific records in a database (filter records) — which required the modification of data connection nodes contained within the sourceSet model — would function happily at first, problems would ensue later on when a form’s certification/ubiquitization status would be inadvertently invalidated, for example, because of an unauthorized modification to a certified/ubiquitized model (sourceSet).

Acrobat 8 and XFA 2.4

In order to address the problem of inadvertent modifications (by form scripts) to certified/ubiquitized XFA 2.4 forms, Acrobat 8 was designed to prevent the sourceSet model (and any other certified and/or ubiquitized content) from being modified post-certification/ubiquitization. This means that if an XFA 2.4 form, loaded in Acrobat 8+, becomes certified and/or ubiquitized, any attempt by a form script to modify the sourceSet model (as in the two examples I mentioned earlier) will result in a security exception:

GeneralError: Operation failed.
This operation violates your permissions configuration.

One could argue, of course, that this change effectively "breaks" XFA 2.4 forms in Acrobat 8+ but in the end, inadvertently invalidating a form’s certification/ubiquitization status is likely just as bad as a security failure in a form’s script (because it attempted to modify a now-protected model) from a user experience point-of-view. As I mentioned earlier, Acrobat makes no distinction between authored scripts and malicious attacks when certified/ubiquitized content is modified — and neither does the user (in their minds, the content simply can’t be trusted any longer)!

Acrobat 8 and XFA 2.5

With a new version of Acrobat and XFA, there was an opportunity to further improve on the user experience of both certified/ubiquitized and non-certified/ubiquitized forms going forward. It was done simply by ensuring that modifications to any model that becomes protected post-certification/ubiquitization are now prevented from the start (whether the form is certified and/or ubiquitized or not) and by using XFA 2.5 as Acrobat 8+’s “trigger” for imposing the new behaviour.

The result is that we’re now forced to think about security from the very beginning of the form design process by opting to work with copies of the in-memory models (which is achieved by cloning models) rather than with the base models such that our forms don’t fail regardless of their certified/ubiquitized state. With XFA 2.5’s support for "on-the-fly" certification/ubiquitization, a form may become secured and locked-down at any point in its "live cycle" which makes it imperative to use scripting techniques which won’t fail post-certification/ubiquitization.

Legacy Mode

New forms authored in Designer 8.0 will be XFA 2.5 forms by default and you’ll need to use the new cloning technique described later in this article. That being said, if you need things to be back the way they were, there is a way that you can still use Designer 8.0 to design XFA 2.4 forms and that’s by using what’s called the Legacy Mode processing instruction.

Put simply, switch to the XML Source view for an XFA 2.5 form in Designer 8.0 and insert the following processing instruction under the <template> node (as a child element):


The result will be that Acrobat 8.0 will run your form as though it was an XFA 2.4 form — but be aware that this will also prevent you from using any of the new language extensions and APIs that come with XFA 2.5 (more on those in later posts).

(By the way, when you load an older form — earlier than XFA 2.5 — into Designer 8.0, even though the form’s version is upgraded to XFA 2.5, the Legacy Mode processing instruction specifying the form’s original XFA version is automatically added so that your form continues to work properly with respect to the XFA version is was originally designed for.)

Modifying sourceSet in XFA 2.5+ Forms

In order to avoid unexpected security exceptions in your forms after they get certified and/or ubiquitized and to handle the fact that you may not necessarily know for sure at which point in the form’s workflow that it’ll happen (if ever), you need to make sure that when you’re working with the sourceSet model, you’re actually using a cloned in-memory copy of the original sourceSet model rather than using the original sourceSet model directly.

Cloning Form Nodes

Don’t worry: You don’t have to be a scientist to use this simple technique. Using the


method on the node that defines the particular data connection you’re wanting to modify within the SourceSet model and making sure your script keeps using the clone instead of the actual definition will do the trick. This method accepts a boolean parameter which, when set to 1 (or true), will clone the node and all its children (which is definitely what you want to do or else you will only get a shell instead of the full data connection) and return a reference to the in-memory copy.

As an example, let’s consider the following script taken from the Data Drop Down List object (found in the Library palette’s Custom tab):

var oDB = xfa.sourceSet.nodes.item(nIndex);
// Search node with the class name "command"
var nDBIndex = 0;
while(oDB.nodes.item(nDBIndex).className != "command")

oDB.nodes.item(nDBIndex).query.recordSet.setAttribute("stayBOF", "bofAction");
oDB.nodes.item(nDBIndex).query.recordSet.setAttribute("stayEOF", "eofAction");

Notice that the script first obtains a reference to a data connection node found within the original sourceSet model and then goes on to modify some of its properties. In an XFA 2.4 form loaded in Acrobat 8+, prior to certification/ubiquitization, this will function properly although it’ll stop functioning if the form ever gets certified/ubiquitized. In an XFA 2.5 form, however, it’ll immediately fail with a security exception simply because Acrobat 8+ determines that the sourceSet model may eventually become protected and protects it from the start.

Applying the cloning technique to this script is trivial. All you need to do is change the line which accesses the sourceSet model to this:

var oDB = xfa.sourceSet.nodes.item(nIndex).clone(1);

Notice the clone(1) method appended to the end of the statement. At that point, "oDB" now receives a reference to a copy of the original sourceSet model which it’s free to modify regardless of the form’s certification/ubiquitization status. The rest of the script doesn’t need to be modified at all!

Note that you could just as easily store the cloned data connection node into a Form Variable or a variable defined in a Script Object in order to reference it again at a later time if you make modifications to it that you would like to persist while the form is running in Acrobat.

Updated Library Objects

If you had already installed Designer 8.0 and tried using the Data List Box and Data Drop Down List objects under the Custom tab in the Library palette, you more than likely ran into the security exception I described earlier. That’s because those custom objects managed to miss the ever so important update which they required in order to function properly in XFA 2.5+ forms with Acrobat 8+ (as we saw in the previous section).

For your convenience, I’ve posted updated versions of both the Data Drop Down List and Data List Box custom Library objects which you can save to your local system and add to your personal (or shared) Library in Designer 8.0.

Updated: December 11, 2006

Little Things Matter

In case you haven’t discovered this yet, Acrobat 8.0 was released a couple of weeks ago and along with it came a new version of Designer. While the "what’s new" page does a great job at giving an overview of the major new features available in the product (as it’s supposed to do), it doesn’t mention some of the smaller things that can sometimes be just as beneficial — if not more, in certain circumstances — than the larger features.

As a developer, I can say that we certainly wish we would’ve had more time to spend on improving the usability, look and feel and "fun factor" of Designer but some of us did manage to find some time to implement a few changes that we hope you’ll find useful.

Field Editor Overlay

This feature is actually mentioned in the "what’s new" documentation but I thought I would highlight it here again since it was designed to help you accomplish some of the most basic tasks surrounding form design:

This feature isn’t activated by default. You can activate it by selecting the Field Editor command from the View menu and selecting a single object on the canvas.

There are 3 major parts to the Field Editor:

  1. The Name edit box at the top in the tab. It serves two purposes, the first being to display the field’s name and the second being a way for you to edit the field’s name without having to use the Object palette or the Hierarchy palette. To edit the name, just click on the tab to make the in-place edit box appear:

  2. It also provides a Field Type drop down list that let’s you change the field’s type on a whim from, say, a date/time field to a numeric field — in case you initially picked the wrong type of field. To do this, just click on the box in the lower left hand side of the Field Editor:

  3. Last but not least is the fly-out menu button located on the lower right hand side of the Field Editor. This simply gives you quick access to the context menu which would otherwise be displayed if you right-clicked on the field using your mouse either on the canvas or from the Hierarchy palette.

Resizing Check Boxes and Radio Buttons

When I attended the BFMA Symposium last May, a few customers came to me and explained how awkward it was to work with check boxes and radio buttons when resizing them on the canvas. The problem was that resizing these object types would result in a larger content area.

For example, you would start with a check box you just dropped from the Library palette

and you would then use the selection handles to make it wider

The problem with this was that making the check box wider would increase the size of the content area as opposed to the caption area. This is generally a good thing when you’re working with field types such as text fields or numeric fields because making the field wider is usually related to wanting more "space" for the value to fit in the content area. Check boxes and radio buttons, however, are different. Since their content areas are restricted to a box or circle when the check mark or dot appears, their values never take-up more room than that which you see at design-time on the canvas. Therefore, making a check box or radio button wider is usually related to wanting more room in the caption area rather than the content area.

In Designer 8.0, we fixed that so that when you increase or decrease the width of a check box or radio button, you get the following result instead of the old Designer 7.x result (more caption space without increasing the content area space):

From there, you can quickly click into the caption area in order to make the required changes to the caption without having to first resize the caption area after resizing the check box itself.

Library Palette Accordion View

If you installed Designer 8.0 already, you may have noticed something different in the Library palette: We’ve done away with the old row of tabs at the top and have introduced a new layout which I like to call the "Accordion View".

This is how it used to look like in Designer 6.0 – 7.x. This is how it looks now in Designer 8.0 with the new Accordion View.

The biggest difference between the two styles is that the Accordion View now lets you see (or open) more than one tab at the same time. For instance, in the sample above, you can see content from the Standard, Custom and Barcodes tabs concurrently while in the sample from Designer 7.x and earlier, you could only see the Standard tab.

While this may not seem immediately useful for the Library palette, we wanted to try it out to see how our customers would like it. At the very least, I think it gives the Library more of a catalogue feel, which is what we were aiming for in the first place. If the feedback is positive, we may consider applying the concept to other palettes as well. Imagine being able to see the Field, Value and Binding tabs all at once in the Object palette and not having to keep going back and forth between them to remember what you set in a particular property!

Enhanced Selection Borders

Another pain point when working objects on the canvas was the difficulty in selecting various objects depending on how they stacked-up against each other. For example, it was nearly impossible to select a subform that contained a bunch of objects that each touched the borders of the subform.

In order to address this problem, we decided to make the selection borders for container objects (such as subforms, tables, table rows, radio button lists, etc.) a little more sensitive to mouse movement by padding them to make them easier to grab.

For example, consider the address block you can get from the Library’s Custom tab: It comes pre-wrapped in a subform. Have you ever tried to select just the subform in Designer 6 or 7.x without lasso-ing all the fields (which can be difficult if you have a lot of other fields on the canvas) or using the Hierarchy palette to select the subform? I don’t think you could actually do it. This is how the selection border on the subform looks like in Designer 8.0:

Notice the semi-transparent fill between the anchor points (it looks like a purple-ish color in the image above). That’s the padding area that activates the selection of the subform whether it’s selected or not (note that this fill doesn’t appear when the object isn’t selected). Try it yourself and see how it works!

Here it is again, this time on a radio button list that contains three radio buttons:

Eye Candy

Of course, we managed to add a few treats in the package as well since all these usability enhancements are nice but they can be a little dry too and who says a form design application can’t be nice to look at or fun to play with?

Library Accordion View Animation

When you click on a tab in the Library’s new Accordion View, you might notice that it rolls-downs and rolls-up when you open it and close it, respectively. Both actions are actually slowing down as they approach their final dimensions.

Canvas Fading

Try adding or deleting objects on the canvas. You can also see it when you move an object from one location to another or when you undo an action you just did.

What’s changed from Designer 7.1 is that these actions on the canvas all result in fade-ins for objects coming on to the canvas and fade-outs for objects going off the canvas. It’s very subtle but it just makes it a little less jarring (i.e. the actions aren’t so sudden anymore) to manipulate the objects on the canvas.

Shaded Page Backgrounds

Designer 8.0 also added two small modifications to the page (canvas) background. If you create a new form with a single page and set the zoom factor to 25%, you’ll get a nice feel for what I’m describing here:

This is what the page background used to look like in Designer 7.1. In Designer 8.0, you can see that the page gets a nice shadow on its right and bottom borders and the background is now a subtle gradient going from dark to light.

These minor changes may seem insignificant but when you add them all together, they can make a significant impact. Hopefully you enjoy these enhancements as much as we enjoyed putting them into our product and please feel free to test-drive them yourself.

LiveCycle Blog and Google Group

I just got word of two excellent new resources for those of you interested in Designer and LiveCycle, whether you use LiveCycle Designer specifically or the Designer that ships with Acrobat:

Designer 8.0 Now Shipping!

That’s right! The day has finally come. At the moment, Designer 8.0 is only shipping with Acrobat 8.0 Professional. You can download the trial to check it out.

Jeff Stanier, our product manager, has put together a great document detailing what’s new in Designer 8.0. This is a really nice upgrade with lots of really nice brand new features like an integrated spell checker, greatly improved PDF Form importing (as "artwork"), improved digital signature support, test data generation, ability to show all scripts in a container, support for transparency in PNG and GIF image files and much, much more including some nice little usability improvements to make it easier to work with your forms.

In the coming weeks, I’ll be giving more details on these features and I’ll also be transitioning to Designer 8.0 and Acrobat 8.0 for future tutorials, targeting Designer 7.x/Acrobat 7.x only where appropriate.

One of the nice things about Designer 8.0 is that it now supports side-by-side installations along with older versions, making it easy to have Designer 7.1 and Designer 8.0 on the same machine for comparison and testing.

Bug: Unable to Set Caption or Value Font Separately


I was showing someone how to use Designer 7.0 today and came across a bug in the Font palette. I was trying to show them how to make the caption of a text field bold without making the value bold using the Bold (“B”) button on the Font palette however I could only change both the caption and value fonts together, not separately as one should be able to do using the selector control located at the top of the palette (which reads, “Currently editing Caption and Value…” by default).

Using the selector control, you should be able to set it to “Currently editing Caption properties…”, press the bold button and make only the caption font bold. Unfortunately, that’s not what happens. Instead, both fonts (or, the entire field) is changed to bold.

Rest assured, this bug was immediately fixed in Designer 7.1 — a highly-recommended upgrade because tables were introduced in that version, amongst other things.


The good news is that there’s a simple workaround using script. All you need to do is use the Font palette to make sure that the Bold button isn’t activated (that the field isn’t bolded) and then set the following FormCalc script statements on field’s Initialize event using the Script Editor palette:

$.caption.font.typeface = "Myriad Pro"
$.caption.font.weight = "bold"
$.caption.font.size = "10pt"

Feel free to specify a different font name or point size if you like although I would recommend using the same font name and point size as you specified in the Font palette so that the result doesn’t differ too much from what you see on the canvas.

Finally, preview the form as PDF using the canvas’s PDF Preview tab. When the form is initialized (loaded) in Acrobat, the field’s caption font will be set to the type, weight and size you specified.


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.

Designer 7 Training by CYTA

I just noticed that Carl Young himself from “Carl Young Training Associates”: is giving a “new course on Designer 7”: this Fall that looks very interesting (here’s the “full course outline”: if you’re looking for details).

They’ll be in *Phoenix*, AZ, Nov. 13 – 14, 2006, and *Houston*, TX, Nov. 27 – 28, 2006.

Bug: “Page n of m” Custom Object Broken in Tables

h2. Description

If you use the “Page n of m” object from the Library palette’s Custom tab, you may have noticed a bug when you drag that object from the Library directly into a table cell:

== BugPageNoMCanvas.gif ==

In the image above, the “Page n of m” object circled in green is correct whereas the one circled in red is not.

If you preview the form or run it in stand-alone Acrobat, you’ll get something like this:

== BugPageNoMPreview.gif ==

You can see, in the image above, that the green-circled object is showing the correct page information while the red-circled one isn’t showing any information at all. That’s because the text object from red-circled “Page n of m” object contains broken references to the *Floating Fields* which are used to display the current page and page count information.

Continue reading…

Seeing the Entire Value

I’m sure many of you out there have run into problems with fields on printed forms where the value entered in the field was too long to fit within the field’s visible area. The result is a black “+” sign on the lower left corner of the field — not much help in reading the entire content when it’s printed and you can’t scroll anymore:

== ==

What if there was a way to configure the field so that the entered value’s font size would automatically shrink to fit the value within the field’s visible area (down to a certain limit)? Of course, it’s possible the text may end-up too small to read without a magnifying glass but the entire content would be printed nonetheless (as long as the minimum font size wasn’t hit):

== ==

The trick here is to set the field’s *value* font to a size of zero (0) but it’s not as obvious as it may seem…

In Designer, there are two ways to do this:

The first is to use script in the field’s Initialize event (FormCalc in this case but JavaScript would do just fine too):

bc. $.font.size = “0pt”

The second is to use the Font palette. In this case, however, only the *value* font’s size may be set to zero. Attempting to set the font size for the caption (or the caption and value combined) to zero won’t work. To specify the *value* font only, use the _Selector_ widget at the top (highlighted in green on the image below) and pick the _Edit Value_ item. Then, set the font size to zero (highlighted in yellow).

== ==

Previewing as Dynamic PDF

Have you ever lived through the frustration of previewing a form on which you’ve written a simple little script to affect the presence of an object when a button is clicked and pulling your hair out because you keep clicking on the button and nothing happens (object doesn’t disappear, there’s no error message, etc.)? Or maybe you’ve been in a situation where you’ve added script to a button in order to “insert a new instance of a repeatable subform”: and while clicking on the button doesn’t produce one, the submitted XML data file contains entries for each new instance that was added?

Even if you haven’t, it may happen someday so here’s the remedy for the case of the “Common (Static PDF) Flue”…

In Designer, there are two different locations containing settings which affect the type of temporary PDF file created when you click on the Preview tab:

# Under the “File Options” section within the “Document Handling” panel of the “Tools | Options” dialog, you can set the _Default File Type for New Forms_. This type is used on new forms which you preview *prior* to saving (because Designer doesn’t know which format you’ll use at the time of preview). This is set to a static PDF format by default.
# Even if you’ve specified a dynamic PDF format for the _Default File Type for New Forms_, this setting may be overridden by the _Preview Type_ and _XDP Preview Format_ properties in the “File | Form Properties” dialog in the “Defaults” panel once you’ve saved your form. The _Preview Type_ property, set to “Interactive” by default, determines whether the form will be previewed as an interactive (dynamic) form or as a print (static) form. This property supersedes the PDF format. The _XDP Preview Format_ property usually picks-up the _Default File Type for New Forms_ setting and determines what PDF format will be used to preview your form should it be saved as an XDP. (Note that if you’ve saved your form as a PDF file, then the _XDP Preview Format_ setting is ignored).

Now that we’ve covered the different properties which affect the PDF preview format, here’s how to kick that flue I was talking about earlier (so that you actually do preview in a dynamic PDF format and stop pulling your hair out):

# If you haven’t saved your form, make sure the _Preview Type_ is set to “Interactive” and that the _Default File Type for New Forms_ is set to a dynamic PDF format. You may also want to set the _XDP Preview Format_ to a dynamic PDF format while you’re at it.
# If you’ve saved your form as a _dynamic_ PDF, make sure the _Preview Type_ is set to “Interactive”.
# If you’ve saved your form as a _static_ PDF, none of these settings will help you. You must first save your form as a dynamic PDF.
# If you’ve saved your form as an XDP, make sure the _Preview Type_ is set to “Interactive” and the _XDP Preview Format_ is set to a dynamic PDF format.
# If you’re tired of running into these problems and want to avoid them in the future, just set your _Default File Type for New Forms_ to a dynamic PDF format.

I hope this tip improves your form design health. It did wonders for me!

~*Updated:* January 27, 2007~