PDF export for transactions should paginate #740
Description
What would you like?
PDF export for transactions should paginate (multi-page) when content exceeds one page; currently large transaction tables overflow off the page
Why is this needed?
Users exporting transaction PDFs with lots of data currently get unusable single-page PDFs where the table overflows the page. Pagination is needed for correctness and usability.
How could it be implemented?
Investigate the HTML-to-PDF pipeline (html2pdf) used for transaction exports. Ensure proper page breaks and/or CSS for printing:
- Use @media print CSS with page-break-inside: avoid; and explicit page-break-before/after for table rows/headers as needed.
- Ensure the underlying renderer (e.g., wkhtmltopdf / puppeteer / jsPDF / html2canvas) is configured to allow multi-page output rather than rendering to a single canvas.
- Add repeating table header across pages if supported.
- Add integration test or sample fixture with many transactions to validate multi-page output.
- Consider adding a max rows per page fallback if CSS-based pagination is unreliable.
Other information
Problem: When a generated PDF becomes too large (e.g., many/large transactions), the resulting PDF produced via html2pdf is still a single page. The transaction table continues beyond the page boundary and becomes invisible/off-page.
Steps to reproduce (suggested):
- Generate/export a PDF that includes a transaction table with many rows (enough to exceed one page).
- Observe the resulting PDF output.
Actual result:
- PDF is a single page and the transaction table runs off the bottom/right (depending on layout), making entries not visible/printable.
Expected result:
- PDF should automatically paginate to multiple pages so all transactions are visible.
Notes:
- Example scenario mentioned: "large transactions" / large transaction table.
- Likely related to page-break CSS and/or html2pdf renderer configuration.