Refer to the PASSTHROUGH system parameter for a discussion on the GDI printing method versus the "RAW" or PASSTHROUGH method. Note that GDI printing is primarily a Windows topic, but might still apply to A-Shell/Unix if ATE is available on the workstation as an auxiliary print service. In that case, you would need to use COMMAND=SBX:GDIPRT in the printer ini file on the Unix side.
When working in the Windows environment, it is natural to want to do things in the most Windows-like fashion possible so that your A-Shell application appears to function just like "any other standard Windows application." However, a "standard Windows application" does not open a print file to create a report and then send it to the spooler when the report is complete, as does a typical ASB application. Instead, it opens up a "printer context" within Windows' Graphic Device Interface subsystem, and then uses GDI functions to tell the GDI system how to create the report. Even the ordinary text of the report is "fed" to the GDI system, which decides how to render it in a form the printer can use.
Switching to the "standard Windows" technique of creating reports would force you to have to rewrite all of your report programs, and several new language statements would have to be added to BASIC to support it. Since this doesn’t seem practical for the majority of A-Shell programmers who have already developed large numbers of report programs, A-Shell does the conversion dirty work for you. It does this by taking the report file which you sent to the spooler, and then feeds it to the GDI system for you, along with some initial directives to establish the printer orientation, font, etc.
Where does it get these "initial directives?" First, it consults the printer’s initialization file, where it may find such directives as FONT, FONTWIDTH, FONTHEIGHT, ORIENTATION, TMARGIN, LMARGIN, etc. Based on the parameters found there, it creates a suitable printer context and then feeds the contents of your report file to the GDI using that context.
The only problem with this technique is that it doesn’t give you any opportunity to change fonts or issue other special printer graphics commands in the middle of the report. (Even if you knew the printer type in advance, it generally doesn’t work to embed actual escape sequences in the report when using this technique, because the printer driver called by the GDI system to process the text is likely to try to render them graphically as special characters.) To deal with this problem, the A-Shell embedded print directives were developed. These commands may be embedded directly in the print file (as their name suggests) but they are logical directives expressed in a form that the GDI system can understand (after appropriate translation by A-Shell) rather than printer-specific escape sequences. Besides the advantage of actually working at all, this technique has the additional advantage of being device independent.
History
February 2010, A-Shell 5.1.1207: GDI Printing refinement: When a //GDI directive fails, the directive itself is printed (rather than the intended effect of the directive). In addition, if the directive failed because of a Windows error, then the error code will be printed at the end of the line, e.g. "(err 1400)". You can look up Windows error codes on the web, or translate them using MX_ERRNOMSG.
March 2008, A-Shell 5.1.1110: This release of A-Shell included a new product/function called "APEX" for A-Shell Preview and EXport. In order to accommodate the needs of the print preview logic in APEX, the core of the A-Shell's GDI printing code underwent a major rewrite. Nothing was changed about how GDI print operations work, and there should in fact be no impact on GDI printing as a result of the rewrite. Nonetheless, the fact of the rewrite is mentioned here so as to keep A-Shell developers well informed.
Subtopics
•Parameters: Symbols vs. Values
