I went on a customer visit and was asked to solve an interesting problem. Basically, this customer had a regulatory PDF form. The form’s layout couldn’t change, and at the end of a workflow process, the form was printed as a document of record. This form was very complicated, with lots of special logic (i.e. “if field 2b is filled, then options 7a, b, and d are no longer available”.) The customer opted to try out Adobe’s Form Guide technology to make the form filling experience better, but once the Guide was complete, we had to take the data from the Guide and push it back to the PDF form (using LiveCycle) and then print the PDF form to paper.
This form had many small fields with instructions indicating that if the field couldn’t contain all the info, to add an appendix page with the rest of the text. Now, in most cases, we would encourage clients to make fields growable, so that they will just expand to fit the text put in them and all the subsequent form content will move down. However, in this case, due to the need for the form to preserve it’s original layout for printing, we couldn’t do that.
It was actually hard to solve this problem: we tried many different scenarios, but most of them were dead ends. The essential problem we kept running into was that the XFA model just doesn’t provide the information you would need to calculate or extrapolate how much text can fit in a given field.
The only solution we came up with that worked fairly well is in the form below. It involves using a fixed-width font in the fixed field, so that reasonable assumptions can be made about how much text can fit into a given field. There’s script that parses text and splits it between two fields. The script is heavily commented, so hopefully readers can figure out what’s going by reading the code.