« Scripting Table Columns
Bug: Unable to Set Caption or Value Font Separately »

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.

This entry was posted on Tuesday, October 31st, 2006 at 12:11 pm and is filed under Scripting, Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

34 Responses to “Expanding to Fit the Entire Value”

  1. Brad Whitaker Says:
    November 8th, 2006 at 1:41 pm

    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. Stefan Cameron Says:
    November 8th, 2006 at 5:07 pm

    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:
    November 9th, 2006 at 2:50 pm

    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. Stefan Cameron Says:
    November 11th, 2006 at 3:38 pm

    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:
    March 12th, 2007 at 4:33 am

    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. Stefan Cameron Says:
    March 15th, 2007 at 10:46 am

    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:
    March 20th, 2007 at 1:19 am

    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. Stefan Cameron Says:
    March 21st, 2007 at 4:18 pm

    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.

  9. Brent Says:
    June 8th, 2007 at 6:19 pm

    Hi Stefan,

    I have a question about using javascript to set the width of a cell in a table. Say we have a table with 1 row as well as a header row (named Row1 and HeaderRow). Also, HeaderRow contains the default text object called “Cell1″ and so does Row1. So basically I just clicked on “create a simple table” with one column and one body row. I can adjust the heights of the rows with the following code:

    Table1.HeaderRow.Cell1.h = “2in”;

    However, when I try to adjust the width with the following code, nothing happens.

    Table1.HeaderRow.Cell1.w = “2in”;

    I can put a text object on the form and adjust either the height or width, but when it’s bound by a table, I seem to only be able to adjust the height.

    Thanks a lot,
    Brent

  10. Stefan Cameron Says:
    June 13th, 2007 at 12:24 am

    Brent,

    Very good question! In order to understand why you can’t adjust the width of a column the same way you can adjust its height, you need to understand a bit about how tables work in XFA.

    Tables are essentially <subform> structures where the table itself is a subform with a special “table” layout (which is basically a top-bottom flowed layout). It then contains subforms as its children which each represent a row. These subforms also have a special layout which is, you guessed it, “row” (basically a left-right flowed or western text flowed layout with some slight differences). Since these special subforms are flowed, you can use Instance Manager objects to add/remove instances of rows within a table and cells within rows — as you’ve done already.

    Now to get to your question, the height of a row is determined by the tallest cell and all other cells are treated as being that height in the layout even if they aren’t the same height — hence why you can adjust the height of a row by setting the height of a cell.

    The width of a cell, however, is set by the column widths defined on the table subform itself in a special attribute called “columnWidths”. It contains a space-delimited list of columns widths. These measurements override any individual cell widths. Therefore, in order to change the width of a cell, you have to change the width of the column it pertains to in the columnWidths attribute which you simply access as a property on the table subform:

    MyTableSubform.columnWidths

    A suggestion for easily editing this attribute’s value would be to use the JavaScript String object’s “split” method to convert the string list into an array of sizes which you can then manipulate. Although the units (”mm”) will also be part of those numbers, you may specify column widths using other units if you wish.

    Last but not least, if the columns don’t appear to render correctly after you set the new column widths, it’s probably because you need to force the form to be re-rendered by using the following statement (this will apply to Acrobat/Reader 8.0 or earlier):

    xfa.layout.relayout();

    This is a similar bug to the one about adding/removing table columns. This issue is fixed in the Acrobat/Reader 8.1 update.

  11. eDesign4Less Says:
    June 18th, 2007 at 5:42 am

    Hiya Stefan,

    You seem to know your stuff around Adobe Designer. I have a small issue, perhaps you can shed some light on the subject because what I am finding is limited and useless.

    I have a form I am developing with Designer 7.0. For some reason, when I add something random (sometimes an image or even changing text) Designer won’t save. I get an error saying it cannot save because of “PDDocSave”. Now I can figure the problem out if I know what the heck that actually does…. Any ideas?

    Thanks,
    Stephanie

  12. Brent Says:
    June 18th, 2007 at 1:36 pm

    Thanks a lot Stefan! I would have never figured out that the column widths are stored in a space-delimited string. This is the first dynamic pdf file I have ever created and you and your site have helped me so much. Thanks again.

  13. Stefan Cameron Says:
    June 18th, 2007 at 10:18 pm

    Stephanie (eDesign4Less),

    I believe the error message you’re seeing is

    “Unable to save PDF document. Error during PDDocSave.”

    According to my colleagues, this error message usually occurs when there’s a problem saving a form as a PDF file. Possible causes could be that the PDF file is currently open in another application (thus preventing Designer from writing any changes to it) or that the system ran out of memory while attempting to write to the PDF file (which could explain why it tends to occur, for you, when you’re adding an image object to a form depending on the size of the image file that you load into it).

    I’m sorry I can’t be more specific than that — hopefully this helps.

  14. Tyler Says:
    July 19th, 2007 at 4:26 pm

    Hey Stefan,

    I have 3 text fields on a page all set to expand and all set to be the same height. Getting the xfa.layout.h for one text field and setting the minH of the other 2 fields to this height. Now my question is when the text field expands over onto a second page the H does grow past the height of the first page. It tells me the height is 265 mm…when there’s another 100 mm on the second page. I do I get the full height when it’s over onto a second or third or more pages.

    Tyler

  15. Stefan Cameron Says:
    August 1st, 2007 at 11:33 am

    Tyler,

    It took me a little while to figure this one out because the documentation on “xfa.layout.h” isn’t very clear. Essentially, you’ll need to make use of the function’s 3rd parameter which takes a “page offset”. What this means is that you need to give it the zero-based index of the page on which you want to determine the height of the field. For example, if the field spanned 2 pages and you wanted its height on the second page, you would do this:

    xfa.layout.h(TextField1, "in", 1);

    The other important piece is how to determine the page index of the first page on which the object appears as well as the number of pages that it spans. For this information, you’ll need to use the “xfa.layout.page” (to determine the one-based index of the first page on which the object appears — a return value of zero likely means that the object isn’t rendered, probably because it’s hidden) and “xfa.layout.pageSpan” (to determine the number of pages that the object spans).

    By using “xfa.layout.page”, “xfa.layout.pageSpan” and “xfa.layout.h”, you can then iterate through all pages that the object appears on and add the heights in order to determine the total height. Here’s an example (in JavaScript):

    var nFirstPage = xfa.layout.page(TextField1); // returns one-based value
var nPageSpan = xfa.layout.pageSpan(TextField1);
var nTotalHeight = 0.0;

for (var i = nFirstPage; i < (nFirstPage + nPageSpan); i++)
{
  nTotalHeight += xfa.layout.h(TextField1, "in", i - 1); // zero-based page offset required
}

xfa.host.messageBox("Total height: " + nTotalHeight); // display total height in message box
  16. Hue Ngo Says:
    March 12th, 2008 at 1:03 am

    Hi Stefan,

    I have a few issues with my form that I am trying to create in Adobe Designer 7. First, I have two options using radio button, each options has descriptions/text fields that need to be filled in once checked. Is there a way that if one option is selected, only the selected description/text fields are visible and the other otpion/descriptions/tex fields will be hidden? Second, what is the script for automatically populate information from one field into another because the checkbox was checked? Third, expanding the field automatically, I have been trying everything that I’ve read from this page and it still does not work. I have the text field that will allow mutiple lines, what is it that I am missing in order for the form to grow when more texts are being added.

  17. Stefan Cameron Says:
    March 12th, 2008 at 11:42 pm

    Hue Ngo,

    1. To show an option when another is selected, see my article that talks about the other field
    2. To pass a value from one field to another when you exit a field, put a line of script in the Exit event of the source field that does something like “MyOtherField.rawValue = this.rawValue;” (in JavaScript). Make sure you address the form objects correctly if they’re nested in subforms. Usually, if they have unique names, this simple script works.
    3. Make sure that the width and height properties on the Layout palette are set to “Expand to fit” depending on whether the field should grow horizontally and/or vertically. You may also need to put the field inside a flowed subform, along with other form objects that follow it, to ensure that those form objects flow downwards when the field’s height changes.
  18. Kyle Says:
    April 3rd, 2008 at 7:44 pm

    Hello Stefan,

    I have two questions.

    Question 1
    I know how to make expandable flowing text fields on multiple pages. But the problem I encounter is when the expandable text field flows onto another page, it creates a new blank page with the expanded text on it. Is there a way to have the expanded text roll over on to the next page of the form, pushing the next pages content down to accomodate it.

    Question 2
    Is there a way to create a text field that has horizontal lines populated in it to accomodate the people that need to hand write in the form while the text perfectly matching up as if it was underlined for the users that electronically fill out the form?

  19. Kyle Says:
    April 3rd, 2008 at 7:46 pm

    oops, forgot to add.
    I am using Adobe Acrobat 8 LiveCycle Designer

  20. Stefan Cameron Says:
    April 9th, 2008 at 2:28 pm

    Kyle,

    In response to question 1: If the expandable text field is inside a flowed subform, all objects inside that subform that follow that text field as it expands in height will continue to flow on the next page just below the text field.

    In response to question 2: I don’t know of a way to produce horizontal lines. The only thing I can think of that comes close is to specify a comb on the field but this only works for single-lined fields.

  21. Kyle Says:
    April 10th, 2008 at 1:38 pm

    Hmmm, I have a subform that encompasses page 2 - page 5, set to flowed with page breaks checked. I think my Hierarchy looks ok, but instead of the expanding text field being on the next page pushing down another text field. It creates a new blank page inbetween for example page2 and page3 instead of the textfield going on page3. Any thoughts?

  22. Kyle Says:
    April 11th, 2008 at 5:31 pm

    Figured it out. Thank you for your time Stefan. The problem was, under pagination, I needed to have the subforms that are created for my pages to be “following previous”, it was defaulted to “top of next page”.

  23. Joey Says:
    April 21st, 2008 at 2:49 am

    Hi Stephan,

    I really need your help! I am currently trying to create forms and I would like to make fields that has the capacity to add in lengthy text. Now, what ive done is put a text box where the lengthy text is to be entered. However, I dont want the textbox to expand (due to dynamic text format), but instead flow onto the next page, ( sort of how microsoft word works) I hope you can help me! Thank u!

    Best
    Joey

  24. Stefan Cameron Says:
    April 23rd, 2008 at 10:51 pm

    Joey,

    It sounds like you should be giving your text box a set width and an expandable height so that it doesn’t grow in width but just in height. Then you would need to put it in a flowed subform and make sure that the subform’s content can break across pages (both these settings can be found on the “Object palette > Subform tab”). Note that all subforms up to the page subform will need to be flowed in order for the text field to successfully break across the page.

  25. Joey Says:
    April 27th, 2008 at 7:01 pm

    Hi Stefan,

    Thanks so much for your reply. I just have another question, in the form that I’ve created, the subform button is not available ( as in it it won’t allow me to click it). I have created this form from an existing document in InDesign. Is that the problem? If I create a new form it will allow me to create a subform. However I need to have the subform available in the existing document to allow me to add text. Please help! and Thank you so much for your time and help..

    Joey

  26. Stefan Cameron Says:
    May 1st, 2008 at 5:40 pm

    Joey,

    That’s the problem: When you import a form as “fixed pages” (as you have done with your InDesign document), you cannot use the subform object. Furthermore, you cannot use “dynamic” features such as “expand to fit” on a text field. This is because the PDF you end-up with, while staying true-to-form to your original document layout, is essentially a static PDF which doesn’t support any dynamic features (e.g. showing/hiding fields, growing/shrinking fields, adding/removing subform instances, etc.).

    I’m afraid the only alternative is to import your form as “flowable layout” however I can’t guarantee that you’ll like the results.

  27. Jacelyn Says:
    June 27th, 2008 at 3:43 am

    Hi,

    I have a question, say if I have 1 text field which I want it to be expandable and I have another text object right beside the text field, my problem is when the text field expanded it overlapped with the text object besides it. Is there any way I can expand the textfield and at the same the text object will also move accordingly?

    Thank you.

  28. Stefan Cameron Says:
    June 29th, 2008 at 1:45 pm

    Jacelyn,

    The problem with the expandable field overlapping the other field beside it is that the fields aren’t in a flowable container (a subform with flowed content). Therefore the second field is fixed in position on the form. If both fields were in a flowed container and the first expanded, the second would automatically be shifted to the right or downwards (depending on the flow direction) to accommodate for the first field’s new width/height.

    You should be able to select both fields and then right-click and choose “wrap in subform”. That will place both fields in a single subform. Then, with the subform selected, set “Object palette > Subform tab > Content” to “Flowed” and, if you want your fields to remain side-by-side, set “Flow Direction” to “Western Text” (which means “left-to-right, top-to-bottom”).

    If you set the flow direction to “Western Text”, increasing the width of the first field such that the second can no longer fit next to it without going outside the form’s right hand margin should cause the second field to essentially wrap around end-up below the first field (on the “second line”).

  29. Kelly Says:
    July 9th, 2008 at 1:48 pm

    Hi Stefan;

    I created a form in Acrobat 8.0 using an MS Word form. It looks fine - the text fields were recognized etc. So far so good. However, I want the fields to expand and I want the entire form to flow and extend on to new pages as text is added to the fields just as it would in word. However the “Expand to Fit” boxes are grayed out for all of my text fields, I also cannot save the form as a Dynamic form as that option does not appear when I save it; my only choices are Acrobat 6/7/8 Static form. I also cannot wrap any of the text boxes in a subform which I read somewhere you needed to do in order to get the form to flow. If I create a new blank form I can save it as Dynamic form so it is extremely puzzling why the converted word form does not allow that option. Do you have any ideas or suggestions for these issues?

    Thank you

  30. Stefan Cameron Says:
    July 14th, 2008 at 7:27 pm

    Kelly,

    The issue here is likely with the way you imported your Word document into Designer: When you import the form with “fixed pages” (a.k.a. as “artwork”), the result is an XFA form with the original PDF (or the Word document converted to a PDF) as its background. While the results are aesthetically precise (i.e. it preserves any kind of special layout you might have had in your original document), this type of form cannot be dynamic (e.g. fields in it can’t expand to fit, as you’ve observed, and you can’t have sections that expand or contract, amongst other things).

    If you import your Word document using the “Interactive Form with Flowable Layout” option in Designer, then you’ll get a form that may not look exactly like your original document however you’ll be able to save it as a Dynamic PDF form and make fields and sections expandable.

  31. Nate Says:
    August 6th, 2008 at 12:51 am

    Hi Stefan. I have 2 somewhat related questions.

    Is there a way to determine through scripting which content area(s) a certain subform is contained in? I have a form that’s a 2 column layout, one content area for each column. I’d like to know if a subform with a text field flows from one column to the other — or is contained wholly in one column.

    Also, I’ve been trying to change the heights of content areas during runtime. Ont he same 2-column form, I have a header area that expands based on the amount of text a user types. I’d like the 2 columns to start directly below that header. I’ve been trying to get the height of the header and using that to calculate a new height for a content area. But I can’t seem to make it work. Is this impossible?

    Thanks very much.

  32. sbrof Says:
    August 13th, 2008 at 4:40 pm

    Dear Stefan,

    I just found your blog and must thank you for the information I have so far gathered. I am having the same problem as Esther above where my expandable text fields that are placed within a Table Cell don’t flow properly. Instead of information being on both the first and second page the whole table row jumps pages. This is a problem is someone inputs more information than one page can hold and Acrobat doesn’t know what to do anymore.

    I have created text fields in subforms that expand properly no problem. I have also gone into the Object\Table, and Row properties and checked “Allow Page Breaks within Content.” Is there anything that you can think of that would be causing problems. If seeing the file would help I have posted it here

  33. Stefan Cameron Says:
    August 13th, 2008 at 6:06 pm

    Nate,

    While it’s possible to determine the page on which a form object is located, I don’t believe it’s possible to determine in which content area on that page it happens to be rendered. You can determine the page using the “xfa.layout.page(object)” function where the parameter is a reference to the form object in question.

    As for resizing content areas at runtime, that’s not possible. There are too many implications with regards to form layout for this to be possible.

  34. Stefan Cameron Says:
    August 18th, 2008 at 12:43 pm

    sbrof,

    I think it’s the buttons (MoveUp, MoveDown, RemoveItem) inside the table row that are preventing the breaks within the Item_OT and Issue_OT text fields.

    If you create a new table with a row containing only multi-line, height-expandable text fields as cells and allow page breaks within the content of the table and the row, the fields should break assuming there’s a common break point amongst the content in all fields/cells.

    Also note that this will only work with Designer 8.2 and Acrobat 9.0 since those versions introduce the ability to break field content across page boundaries.

Leave a Reply

Alternate Help: Unfortunately, I am not always able to keep track of older posts. Please feel free to continue discussions here or seek help at an Adobe Forum: Designer/Acrobat, Designer ES, Designer (v6-v8), Acrobat, Reader.

If you're including scripts: To make sure your script and comment are properly interpreted, please make sure you replace any less-than ("<") characters with their character code equivalent: "&lt;" (without the quotes). Otherwise, your script and comment will inadvertently be cut short. Thank you!