TFPrint Errors and Exit Codes

Exit Codes

Check the process exit status after every TFPrint invocation. For generated files, also check that the expected file exists and is not empty before opening it or reporting success. A success message in a calling script does not establish that TFPrint succeeded.

A zero result from an information command does not indicate that any document was generated. Unsupported -LCUPS, for example on Windows, is a parameter error.

Command-Line Errors

Typical parameter errors include:

• An unknown switch, data type, output type or data/output option.
• Missing -F in the direct mode, or a missing job-file path with -DT TFS.
• A supplied -D without a selected data type.
• TEXT input without a column separator.
• ODBC input without a connection string or SQL query.
• A file-output type without an output filename.
• Missing or invalid fields in the seven-field license form.
• A command file that cannot be read or parsed.

See Required Parameters and Parameters. Some parser errors terminate immediately, so later arguments are not processed.

SDK and Output Errors

Failures while loading layouts or data, applying configuration or licensing, selecting printers, or generating output are reported as errors. The output-processing path returns the error value from the failing operation and can report the full value in an Error Code: 0x... hexadecimal diagnostic; for license errors this line can appear twice. Use the actual code and diagnostic text from the failed invocation. Initialization failure can include a previous operating-system error and its description.

For printer output, distinguish the default-printer path from an explicitly selected printer or CUPS queue. An unavailable destination is an error; a returned process status does not replace checking the queue and printed result.

An unavailable printer or an empty explicit CUPS queue can return 1801 (ERROR_INVALID_PRINTER_NAME). Default printing also requires a configured, available default printer. For explicit CUPS output, supply the configured queue name with -O; see Output target.

If the CUPS library is unavailable, a CUPS-enabled runtime can print Warning: Cups was not found. Cups support will be disabled. on stderr. Check the CUPS installation and runtime dependencies before retrying printer output.

Windows and Linux Callers

Keep the return value provided by the process API when launching TFPrint from an application. In a batch or shell script, check the status immediately after TFPrint, before another command replaces it.

Some callers expose only an 8-bit process status. For such a caller, -1 appears as 255, and an error value of 1801 appears as 9 (1801 modulo 256). Use the full hexadecimal diagnostic on stderr when the caller's status is truncated; do not interpret the truncated number as a complete SDK error code.

stderr and Diagnostics

TFPrint writes command-line errors to stderr. Normal progress messages use stdout. Capture both streams when an application or unattended script needs a complete diagnostic record.

-Q suppresses normal progress messages and the synopsis/help display once it has been read. It does not suppress errors on stderr, and it does not suppress the output of -LCUPS and -SYSTEMID, which write directly to stdout and terminate after their request. Place -Q before the output it should suppress; see Other Options.

Before retrying a failed invocation, check the layout and data paths, format-specific parameters, runtime dependencies, license configuration and destination. See Windows deployment, Linux deployment, Licensing and Troubleshooting.