File-Print

Like most Windows applications, Design sports a File-Print operation and has the standard Print icon on its toolbar. But it's not really a normal print operation.

Virtually always, when you want to see how your form design is coming along you will do a Tools-PDF Preview..., Tools-HTML Preview..., or Tools-Merge Test... operation. File-Print is almost never used.

What File-Print does is to use "Windows drivers", as in Default-WIN.prt , to print out a blank document. It does not matter which printer configuration is defined for the form design, the Default-WIN.prt configuration file will be used for File-Print.

So it is not emitting PCL or PS2, or PDF, but is rather making Windows GDI calls suitable for devices known to the Windows system for which there are device drivers from the device's vendor. Adobe PDF is often another output choice that can be made. Just as Microsoft Word, or any app, can output to the Adobe PDF pseudo device, DocOrigin's GDI calls can be directed to the Adobe PDF driver to create a PDF.

But this is not really a data merge operation. File-Print prints a blank form.

The other interesting fact is that for File-Print, Design makes it as if every pane and every table row were mandatory, occurring once. Hence the File-Print operation produces a blank form with every pane and table row in it. This could be useful for form design documentation. For simple static forms, a File-Print result could be used for simply printing a form, e.g. for "print-then-fill" operations.

It's likely that you want to use Tools-Preview PDF and specify an applicable test data file, but File-Print can be used for a blank form using Windows drivers technology.