Expanding to Fit the Entire Value

A while ago, I posted an article detailing a trick to make the value of a field be displayed entirely within the field’s content area. Essentially, by setting the value font size to zero, this tells Acrobat to shrink the field’s content area (value) font at will to make the entire value entered fit horizontally. This can certainly be useful but there’s one significant drawback: the value font may shrink such that it becomes too small for anyone to read depending on how much data the user enters into the field.

Fortunately, there’s an alternative method to making a value fit within a field’s content area when you don’t know how long the value will be: Making the field’s width and/or height expandable!

The advantage of this solution is that the value font’s size remains constant (the same as which you specified it to be when you designed the form). When a field is make expandable, its "w" (width) and/or "h" (height) attributes are replaced by "minW" (minimum width) and/or "minH" (minimum height) attributes, respectively. These attributes define the initial and minimum size of the entire field (that is, its caption and content areas combined). When the width is extended, however, only the field’s content area is increased in width. Its caption area remains the same width. On the other hand, causing the height of a field’s content area to be extended will also cause the caption area’s height to be extended.

Making a Field Expandable

Specifying that a field’s width and/or height is to expand to fit its content is quite simple: You just need to check the "Expand to fit" check box that pertains to the width and/or height property on the Layout palette.

Getting a Tight Fit

So far, you’ve learned how to make a field’s width and/or height expandable, essentially by specify a minimum width and/or height instead of a set width and/or height. Now what if you wanted to ensure that the field’s width and/or height was always just wide enough to contain whatever value was entered? For example, you don’t want a whole bunch of empty space if you set a minimum width of 2 inches to have a nice initial size to enter a value into the field but the user only entered a value that required 1 inch to be entirely displayed.

In that case, you could simply set the minimum width to zero when the user leaves the field, if they’ve entered a value. This is done by scripting the field’s Exit event (shown here in FormCalc):

$.minW = "0"

Look-out for Long Values!

One thing you have to look-out for is extra long values — especially if you haven’t specified a maximum length for the field. If the user enters too much data, the field might simply run off the page.

If you don’t want to set a maximum data length for the field but you don’t want it to expand beyond a certain width, you can set a maximum width and/or height. Since Designer’s UI doesn’t let you set this property directly, you can use the field’s Initialize script to set it (shown here in JavaScript):

this.maxW = "4.5in"; // max width of 4.5 inches

Note, however, that if the user enters more data than can fit within the specified maximum dimensions, the value will be cut-off and won’t print so you may consider setting a maximum data length or resorting to the previous solution (setting the font size to zero).

Sample

This sample form implements the solution I’ve described in this post.

Download Sample [pdf]

Minimum Requirements: Designer 7.x, Acrobat 7.x.

8 Responses to Expanding to Fit the Entire Value

  1. Brad Whitaker says:

    Is there a way to determine within a script whether or not the text fits within the field? Acrobat/Reader give the visual clue (the + sign) but I can’t find any documentation indicating that this “status” is available programmatically.

  2. Brad,To my knowledge, this kind of information isn’t available via the scripting API.If you’re trying to grow the field such that the text always fits, I would suggest you make the field’s width and/or height expandable using the Layout palette. This will ensure that the text always fits (and is always completely visible).

  3. Brad Whitaker says:

    Thanks for the response. Expanding the field is not appropriate for my application. I wanted to do a kind of “pre-flight” print checking to make sure that all content will be visible within the fixed amount of space that has been allocated. Since I’m using variable width fonts I can’t just restrict the number of characters.

  4. Brad,I think I understand your problem a little better now. You may still have some options:Acrobat 8.0 Dynamic XML Forms: Using Designer 8.0, you can check the “Limit Length to Visible Area” box on the Field tab in the Object palette. This may also work using Designer 8.0 and saving the form as an “Acrobat 7 Dynamic XML Form” but it wouldn’t really be supported.Acrobat 7.x PDF Forms: If you’ve saved your form as an Acrobat 7.x PDF form, you can set the Acrobat Field Object‘s doNotScroll property to “true” in order to limit the value’s length to the field’s visible content area as follows, in JavaScript only:event.target.getField(GetFQSOMExp(this)).doNotScroll = true;Note that this must be done in the field’s Enter event (when the field receives focus). Doing it in the Initialize event is too soon and you won’t have access to the pertaining Acrobat Field Object in order to set the doNotScroll property.In both cases, this will limit users from entering more text than can fit into the content (value) area of a field. It’s different from setting a maximum character length for the field in that it takes variable width fonts and kerning into consideration.

  5. Esther says:

    I have created a table with auto-fit textbox in the repeating row. Although I have set both Table and Body Row property to “Allow Page Break within Content”, the table still run off the page for bulky input (start from the first row of second page). How can I fix this?

  6. Esther,If I understand correctly, the text field within the table row isn’t splitting in two parts with the beginning on page 1 and the remainder on page 2, for example. Instead, the entire table row gets moved onto page 2.To make sure that the text field within the table row is split into two parts, the table must be placed within a flowed container (that is, a subform with its Content Type property set to “Flowed” — set this via the Subform tab in the Object palette) and the table and table row must both have the “Allow Page Breaks within Content” option checked (also set via the Object palette’s Table and Row tabs, respectively).

  7. Esther says:

    Thanks very much! I just miss the “Flowed Container” that you mentioned.I am creating a table with following spec. but the result is not what I expected, so wonder if it is possible in Pro 8:One subform container for the table body which just repeats once, and the table body itself contains 10 rows, with column one a positioned subform, so that I can put different elements for each row.I can’t make it right as the page break problem happened once again. So it is impossible to make a flowable table with not just using the repeating content?

  8. Esther,A flowed container (subform or table) is required if you’re going to make something within it repeatable.You should be able to select the default text object contained in the first column of a row and change its type (via the Object palette Field tab’s Type property) to a subform. This will give you a positioned subform as a table cell. At that point, if you want the subform within the cell to split across pages, I believe you’ll also have to make it flowed. You can always add a further level of nesting using positioned subforms in order to position fields within that subform at precise locations.