Jetformat

Make HTML PDF capture wait for meaningful content

Wait for a meaningful page state instead of relying only on a fixed delay. The Jetformat HTML beta uses a separate renderer service, so test that dependency before debugging page content.

Published · 4 min read

By Jetformat

1. Keep local assets with the page

Use a directory input when a report depends on local stylesheets, images, or fonts. Passing an isolated HTML file while leaving its assets elsewhere makes a successful capture less useful.

jetformat html to-pdf ./report-site -o report.pdf --page-size A4

For a deployed URL, supply an explicit output path. Verify that the renderer can reach the page and all required resources. A browser on your laptop reaching a private URL does not prove that a separately hosted renderer has the same network access.

2. Define readiness in the page

jetformat html to-pdf ./report-site -o report.pdf   --wait-ready '.dashboard-ready'   --wait-visible 'svg.chart'   --wait 2s

Choose selectors that correspond to completed report data and visible chart content. A selector that exists before a network request completes is a weak readiness signal. The fixed delay is supplemental; it should not be the only explanation for why capture is reliable.

3. Separate connection and rendering failures

The service address comes from --server, JETFORMAT_HTML_SERVER, or its default. A connection failure is different from a blank chart, missing font, or print stylesheet that hides content. Establish connectivity first, then inspect the captured result.

Run pdf info to check page count and render a representative page to inspect fonts, chart labels, and page breaks. Office conversion and local PDF operations do not depend on this HTML endpoint.

See HTML-to-PDF setup and the HTML task guide.

Last updated