Dynamic PDF Layout Troubleshooting

A Dynamic PDF is built from the content of your PDF template. When the PDF is generated, each wildcard is replaced with the submitted value. A layout that looks right in the editor can change once real values of different lengths are filled in. Find the problem you're seeing below.

On This Page

• Where to edit the template HTML
• Labels move when the values are filled in
• A fill-in line breaks around the value
• A table with a conditional row prints with shifted cells
• Amounts print without a currency sign

Where to edit the template HTML

Most of the fixes below are made in the HTML of the template body:

1. Open the form in Form Designer.
2. Click Post Processing > PDF Generation.
3. Select your template and click Edit PDF Template.
4. Click Next until you reach Head, Foot & Body Content, then click Edit Document Body.
5. Click Source in the editor toolbar to see and edit the HTML.
6. Click Save & Close, then click Finish.

To check a change, generate a new PDF. Testing and Debugging Dynamic PDFs shows quick ways to do that.

Labels move when the values are filled in

Symptom: Labels look lined up in the editor, but in the generated PDF a label that comes after a wildcard on the same line moves left or right. Where it lands depends on how long the submitted value is.

Cause: Each wildcard is replaced with the submitted text, so everything after it on the same line moves with the length of that text. Spaces between the labels don't hold them in place.

Fix: Put each label and each wildcard in its own table cell, and give the label cells a fixed width. In Source view, use a table like this, with your own wildcards in the brackets and widths that fit your longest label:

<table border="0" style="width:100%; border:none; border-collapse:collapse;">
  <tbody>
    <tr>
      <td style="width:110px; border:none; vertical-align:top;">Printed Name:</td>
      <td style="width:250px; border:none; vertical-align:top;">[Printed Name]</td>
      <td style="width:80px; border:none; vertical-align:top;">City:</td>
      <td style="border:none; vertical-align:top;">[City]</td>
    </tr>
    <tr>
      <td style="border:none; vertical-align:top;">Address:</td>
      <td style="border:none; vertical-align:top;">[Address]</td>
      <td style="border:none; vertical-align:top;">Company:</td>
      <td style="border:none; vertical-align:top;">[Company]</td>
    </tr>
  </tbody>
</table>

The table prints without borders, and a long value wraps inside its own cell instead of pushing the next label.

A fill-in line breaks around the value

Symptom: You typed underscores to draw a fill-in line and put a wildcard on it. In the PDF, the value prints between two pieces of line instead of on the line, and a longer value makes the whole line longer.

Cause: The underscores are ordinary text. The wildcard is replaced with the value, so the underscores before and after it stay as two separate pieces.

Fix: Draw the line with the bottom border of a table cell and put the wildcard inside that cell:

<table border="0" style="width:100%; border:none; border-collapse:collapse;">
  <tbody>
    <tr>
      <td style="width:110px; border:none;">Case Name(s):</td>
      <td style="border:none; border-bottom:1px solid #000000; padding:0 6px;">[Case Name]</td>
    </tr>
  </tbody>
</table>

The value prints on one line that keeps the same length for every entry.

A table with a conditional row prints with shifted cells

Symptom: A table that shows a row only for some entries prints correctly for some entries but not for others. The cells of the next row move one column to the right and an extra column appears, or a row you meant to hide still prints with an empty value.

Cause: Two setups cause this:

• A row hidden with display:none next to a rowspan cell. When the row is hidden, the cell that spans it still takes its column in the next row, so that row's cells are pushed to the right.
• An inline condition wrapped around a whole row. The editor moves {IF ...} and {ENDIF} out of the table, so the row is no longer conditional and always prints.

Fix: Put the condition inside a table cell, and don't use rowspan on a cell next to a row that may be hidden. For example, this prints the corporation lines only when [Entity Type] is Professional Corporation:

<table border="1" style="width:100%; border-collapse:collapse;">
  <tbody>
    <tr>
      <td style="width:50%;">Party: [Printed Name]{IF [Entity Type] = 'Professional Corporation' THEN}<br />- and -<br />Corporation: [Corp Name]{ENDIF}</td>
      <td>Contact: [Address]</td>
    </tr>
    <tr>
      <td>Start Date</td>
      <td>End Date</td>
    </tr>
  </tbody>
</table>

Inline conditions have no ELSE, so use a separate {IF} for each case.

Amounts print without a currency sign

Symptom: A field with Validation set to Currency prints as a plain number in the PDF, for example 98000 instead of $98,000.00.

Cause: Validation only checks what is entered on the form. It doesn't change how the value prints.

Fix: Format the value in the PDF, or format it on the form.

Format it in the PDF (the saved value doesn't change):

1. In the PDF editor, highlight the wildcard, for example [Amount].
2. Click Wildcard Modifiers in the toolbar.
3. In the WildCard Functions list, double-click currencyFormat.
4. Choose the Currency Symbol and click Save.

The wildcard becomes currencyformat([Amount],'$') and prints as $98,000.00. See Wildcard Modifier Functions for more formatting options.

Format it on the form (the value is saved with the currency format):

1. In Form Designer, select the field.
2. In Field Properties > Field General Setting, set Mask to Currency US.
3. Click Save.

The value is saved as, for example, $98,000.00, so it prints that way in the PDF. As people type, the mask fills in from the right: typing 123450 shows $1,234.50.