Jetformat

Build a document batch pipeline that checks its outputs

A dependable batch has separate preflight, write, and verification stages. Keep the source files and identify each output explicitly so a failed job cannot be mistaken for a finished document.

Published · 4 min read

By Jetformat

1. Preflight before conversion

Validate each input and inspect its structure before scheduling writes. Validation checks file structure; inspection supplies format-specific information such as visible worksheets or slide counts.

jetformat validate report.docx
jetformat word inspect report.docx --json

A valid package can still contain unsupported content or unavailable fonts. Keep those checks in the acceptance criteria instead of interpreting a successful validation as a promise of visual fidelity.

2. Write to a distinct output path

jetformat word to-pdf report.docx -o report-output.pdf

Use a job-specific output directory in a real batch. Decide explicitly whether reruns may overwrite prior outputs. The CLI’s --force option should follow that decision rather than being added to every example by habit.

In shell automation, inspect the exit status before proceeding. Do not announce an output merely because the expected filename can be constructed: an older file at the same path can survive a failed run and mislead downstream steps.

3. Verify both structure and appearance

jetformat pdf info report-output.pdf --json
jetformat pdf render report-output.pdf --pages 1 --width 1600 -o report-preview

Compare page counts with expectations and review representative pages, especially around tables, page breaks, or font changes. Reading metadata is free, while rendering previews uses page-based credits.

When an error occurs, retain enough information to reproduce the input type, command, version, and failure without logging private document contents. See unsupported files, font checks, and billing behavior.

Last updated