The PDFX document generation process is almost ridiculously easy to envision and understand. Because A-Shell is used in different environments (Linux, AIX, Windows, etc.), there are different ways that A-Shell and therefore PDFX are configured. But the block diagram is the same in all cases:
| • | A virtual printer is set up in A-Shell. This consists of a building a simple .INI or PQI printer initialization file, just like one would do for any other printer. |
| • | A report is generated in A-Shell, and appropriate PDFX directives are programmatically embedded in the report. Examples of GDI directives, which are formated and handled like other GDI directives, are functions like "Overwrite file if it already exists," "Email finished document to specified address," "Analyze for links and make the links live," "Embed fonts," etc. A GDI directive looks like this: //PDFX,Save.WhenExists,1. |
| • | The report is sent to a PC where the PDFX driver is installed, and the driver interprets and executes embedded PDF directives. |
That's basically all there is to it. There are other details to attend to in the set up, of course, such as installing the PDFX drivers on the applicable PC(s), and making sure that the report is delivered to the PC(s) where the PDFX drivers are installed.
In the simplest A-Shell environment, a stand-alone Windows PC running A-Shell, enabling PDF generation and processing is a matter of perhaps five minutes; define an A-Shell virtual printer, install the PC drivers, and print. Really. That's all there is to it.
In more complicated A-Shell environments, delivering the report from A-Shell running on, say, AIX or Linux, to one or more PCs on a connected LAN, is a little more involved; but A-Shell has the tools and functionality to manage delivery of the reports in a straightforward matter. In such circumstances, one would use either ATE (A-Shell Terminal Emulator) or AshLPD (A-Shell's network print server) as the "transport" mechanism for delivering the report.
