gravity-pdf
gravity-pdf copied to clipboard
Keep fields in the rows/columns they start in
Description
When handling columns in Core templates, we will display any field in a column if it has enough space to fit, regardless of if they were in the next row in the form. This allows for users to use conditional fields that will be displayed in the correct column location. However, this also applies to empty fields when the Show Empty Fields option is off.
Providing the best of both worlds would be ideal, but it isn't something we can entirely automate. We could add a row separator class that keeps fields in their own row when a user adds it to a field. Alternatively, we could have a "faux" field like we did pre-2.4 that could be optionally enabled.
The "faux" field option has its merits but it would cause issues with the conditional logic use case if we applied this to the entire form automatically. A CSS class applied to specific fields/pages/sections (if applied to a section the faux feature would apply to any fields in that section, and if applied to a page it would apply to all fields within that page) that allows users to opt-in to this layout option would be suitable. It has the added benefit of keeping fields in the same column structure as the form editor, which the row separator option does not.
Step To Reproduce Steps to reproduce the behavior:
- Download and import gravityforms-export-2021-10-17.json.txt
- Fill out the first two fields in row 1 and the first two fields in row 2
- Submit the form and view the PDF
Expected behavior You can see one of the row 2 fields are being sucked up into row 1. Being able to turn this off on a case-by-case basis would be helpful.
Screenshots

Alternatively, we could have a "faux" field like we did pre-2.4 that could be optionally enabled. It would cause issues with the conditional logic use case I mentioned earlier if we applied this to the entire form automatically, but a CSS class applied to specific fields/pages/sections that allows users to opt-in to this layout option would be suitable. It has the added benefit of keeping fields in the same column structure as the form editor.