This question keeps coming up, so perhaps it's time to revisit it:

What's the best way to create reports in the UNIX environment contain graphics and are device-independent?

Under Windows, A-Shell's GDI format is a pretty good choice - easy to use, well-supported, device-independent.

Under UNIX, it's not quite as good of a solution, since in order to render it on an output device, you have to pass through the A-Shell/Windows print engine. Our traditional answer to that has been twofold:

1) If you use ATE, you can just set up virtual printers on the UNIX side using DEVICE=AUXLOC:{ATE-printername} and let ATE handle all your GDI printing operations (including preview and PDF generation.)

2) Or, set up one or more AshLPD software "printers" somewhere on the network, and use it more or less like you would use any other network printer device in the UNIX world. One instance of AshLPD can handle any number of print queues and real printers, and supports both the standard LPR/LPD protocol as well as A-Shell's proprietary ASHLPR protocol. (The latter protocol is able to deal with embedded //IMAGE and //XTEXT references.)

Still, some people find that neither of these solutions is as clean as they would like, because they can't just execute a UNIX lp -d<printer> <filename> command line to send a GDI-formatted file to any printer. Of course, to be able to do that for any other graphics format usually requires a print filter to perform the necessary translations, but such filters do exist for other common graphics formats, whereas they don't for A-Shell GDI (unless you're willing to call AshLPD a print filter).

So, what's the best solution? Two possibilities come to mind:

A) Do away with A-Shell's GDI and code your reports in some other standard graphics format. Ghostscript/Postscript seems like a good candidate here, but there may be others. The main downsides I can see are:

a1 - You've got a lot to learn, and a lot of coding work to do - much more than just inserting a couple of //GDI directives in your printfile. (Postscript, for example, is a wonderful language, but the reference manual is over 750 pages long, compared to a about a dozen pages for A-Shell GDI.).

a2 - The resulting report files might be more standard in the Linux world, but not necessarily easier to work with in other environments. In particular, ATE/APEX would probably not understand it, thus closing off a fairly common route for UNIX printing/previewing.

(See Printing PDF files (UNIX to PC) for a recent related discussion about direct generation of PDF files under Linux.)

B) Create a UNIX-compatible filter that translates A-Shell's GDI format into something more directly printable (PCL? Postscript?).
This seems doable, since our GDI format is pretty simple and straightforward. The main complications I can envision are:

b1 - Some calculations (like auto-pitch) require the ability to query the printer device to determine its capabilities. This is presumably possible in other environments, but I'm a little unclear on how that would work in a filter that translates GDI to, say, Postscript, since the translation operation should remain printer-independent.

b2 - //XTEXT presents a particularly complex challenge, since the implementation is buried inside a Windows control, and outputs directly into a Windows printer device context. Essentially, that function of XTEXT would have to be completely reverse-engineered. (Perhaps not too difficult for plain text, but RTF is another matter.)

On the other hand, there is nothing in the above that prevents anyone (even someone with minimal A-Shell familiarity) from developing such a filter. It could be written in A-Shell/Basic, or C, or Java, or Perl, or just about any other language.

I'm hoping that the various people who have done something in this area, and/or are looking for the best approach to adopt, can get together and share their experience and ideas here...