Although AUXLOC printing (from a server to the ATE client via the "auxiliary port") supports GDI commands (provided the client really is ATE), a complication arises with GDI commands such as //IMAGE (and //XTEXT) which reference other files.
In the standard A-Shell/Windows environment, there is no confusion, because the GDI processing takes place in the same environment as the print file was created in, and thus the referenced image and/or XTEXT files are going to be visible to the GDI processor. But when the file is created on the server, and printed on the client, those auxiliary image and xtext files are not going to be visible to the GDI processor, resulting in the //IMAGE and //XTEXT commands being printed as plain text (which is how the GDI processor handles commands that fail) rather than as images or embedded documents.
One solution is for the application to arrange to transfer all the relevant image and/or xtext files to the PC prior to initiating the AUXLOC printing operation, but unless you are dealing with a static set of images that are used all the time (in which case you should park them in the %ATEPERMCACHE% directory permanently), manually transferring them each time is going to be a bore.
An improvement on that would be to create all your printing-related images in a single directory, and then ATSYNC that directory to %ATECACHE% prior to printing. But if the number of files handled this way gets large, this might start to become inefficient. (Even though ATSYNC only transfers files that are new or changed, it still has to look at them all and compare them).
The latest solution, which is considerably more convenient, is to install the new ATPXFR.SBX print filter (available in the SOSLIB [907,29] directory, as of SOSLIB 154), as well as an updated copy of ATEAPX.SBX (also from the SOBLIB, but in the ATE utility directory, [907,33]) into the BAS: directory on the server. Then invoke in in the printer init file on the server as follows:
DEVICE=AUXLOC:
COMMAND=SBX:ATPXFR
The ATPXFR filter pre-scans the file you are printing for any //IMAGE or //XTEXT commands, and if found, transfers them to the %ATECACHE% directory on the ATE client using ATEAPX.SBX. It is smart enough to avoid redundantly transferring the same files over and over again (e.g., if you have a logo printed on each page), and transfers the files via the existing TCP connection (telnet or ssh) so there is need to worry about FTP issues that might otherwise complicate matters.
Note that even though your print file may reference the image files using server-based filespecs, e.g.
//IMAGE,DSK9:MYLOGO.JPG[123,456],10,20,100,200
ATE will check the %ATECACHE% and %ATEPERMCACHE% directories if it can't find the image where you said it was, and thus there is no need to actually modify the //IMAGE statement in the printfile itself.
(On a related note, ASHLPR/ASHLPD will automatically do the same thing, provided you use the proprietary ASHLPD protocol rather than the standard LPD protocol.)
