Here's the question: how does one print a PDF file in a UNIX/telnet environment?

(In this particular case, the telnet client is ATE, so perhaps this could have been filed in the ATE forum, but at least part of the problem and solution would probably apply equally to other emulators, such as ZTERM, which can be commanded to do things by the application via ESC sequences.)

Note that there may well be ways to print an existing PDF directly from the UNIX environment (if anyone has an idea, please suggest it), but for now we are assuming that the best way to get the file printed is to send it to the PC client and have it printed in the Windows environment.

So, there are two parts to the problem:

1) Getting the file from the UNIX server to the PC

2) Getting it printed from the PC

Note that we can't just print a PDF as if it were a "printable" (i.e. text, PCL, GDI, etc.) file, unless you happen to have a printer which understands PDF format. So the problem is going to be a little more complicated than simply sending it to an A-Shell spooler on the UNIX side which uses DEVICE = AUXLOC:

So,

Step 1 (transferring the file) : There are plenty of ways to do this (such as plain old FTP, i.e. via the ZTERM ESC sequence or via AG_FTP ). If you're not sure that FTP is available, a cleaner (and except for really large files, faster) method would be to use ATEAPX.SBX (from the SOSLIB) with flags=4 (binary mode, 'null' printer). This converts the file to MIME format (in case it contains binary data) and sends it down the existing telnet/ssh connection to ATE, which decodes it and writes it to disk. If you're sure that the PDF file doesn't contain any problematic binary characters, you might well be able to use flags=6 (ASCII mode, 'null' printer) to make it that much more efficient. (But I'm not sure you can count on PDF files not containing nulls or other control characters that might get misinterpreted if just sent down the line directly.)

Step 2: Tell the ATE (or other) client to print the file. As far as I can tell, this requires some kind of trick. One kind would be to use an existing PDF reader which supports a command line option to send the file to the printer. (The Acrobat Reader probably does this, but I've been unable to discover the necessary command line syntax.) But there are lots of PDF utilities out there, surely one or more of which support an option to print a PDF using a command line. (If anyone knows anything about this, please share your secrets!)

Armed with such a command line, you can invoke it via MX_SHELLEX

Another kind of trick would be to create a GDI wrapper document which contained little more than the PDFX Overlay.xxxx commands necessary to invoke the PDF file as an overlay. (See http://www.microsabio.com/documents.html for PDFX documentation)

You may also want to read Printing PDF File Automatically (elsewhere on this forum) which discusses (however obliquely) both techniques, including the use of the Docu-Track PDF viewer for printing existing PDF files.

After getting a handle on the two parts of the problem, you may want to encapsulate your solution into a print filter, which could be set up something like this:

On the server side, create a printer init file (let's call it PDFPRT.PQI) which contains something like:

COMMAND = SBX:PDFPRT,,

You would then create your own PDFPRT.SBX which transferred the PDF file to the PC (I would suggest ATEAPX.SBX for this), and then invokes your PDF printing command line (e.g. with MX_SHELLEX).

Or, if you plan to use the PDFX Overlay technique, your printer init file would also have a DEVICE = AUXLOC: statement, and your PDFPRT.SBX print filter would need to do the following:

a) Create the GDI wrapper containing the PDFX Overlay command to invoke the desired PDF file as an overlay,

b) Pass the name of that wrapper file back in the FILE parameter

c) Pass STS back set to 1 so that the print operation proceeds using the DEVICE=AUXLOC: mechanism.

(See Printer Init > COMMAND > A-Shell processing for more information about print filters.)

In either case, you'd then be able to do this on the server side:

.PRINT PDFPRT=xxxxxx.PDF
or
XCALL SPOOL,"xxxxxx.PDF", "PDFPRT"

Keep in mind though that if using a Windows utility to invoke PDF printing via a command line, you'd need to make sure it was installed on each PC. (You might be able to use MX_FILESTATS to verify that the necessary utility was present, and prompt the user accordingly if not.) PDFX would eliminate that issue, but introduces a license cost.

Sorry to presented something so seemingly simple as absurdly complicated, but that's printing for you. On the bright side, once you work out the details and encapsulate them in your print filter, it will indeed seem as simple (to the user or the app) as you had imagined it to be.

For years now we have been using ghostscript to create a PDF invoice. The first call creates the PDF from multiple files of images, text, and a signature block. The second call sends the PDF to the printer. Our printers are setup to do postscript printing.

When we get a chance we are going to simplify things by creating a template and just overlaying the text. Then use ghostscript to print the PDF.

If anyone needs to see the code let me know.

Have a nice upcoming springy weekend.

Indeed, I (for one) would be interested in the 2nd part of your procedure (i.e., sending the already-created PDF to the spooler).

Is it just a matter of having the proper spooler configuration (filter) to accept and properly render spooled PDF files into a format the printer can understand (i.e. postscript)?

I have to hit the highway, so this will be short.

We set the printers to genric/raw then we use ghostscript to send the created PDF to the printer. We only use printers that understand postscript/PCL.

SYS'CAL="gs -q -dNOPAUSE -sDEVICE=ljet4 -r300 -sOutputFile=\|'lpr -P"+
PRNTR'NAME+"' "+INV'IMAGE'PATH+AS'FILE[1,AS'FILE'LEN]+ &
"pdt -c quit"

On one flavor of Fedora we needed to print duplex and it would not pass the code, so we had to set the printer filter to do postscript and then we just printed the pdf to it.

I don't know if this makes any sense, but have a good one and see you later.

Interesting. So you execute that via HOSTEX I presume?

Can I put you down to teach a seminar in ghostscript printing at our next Conference?

In any case, thanks for sharing.

And be careful out there on the road. (Despite the arrival of modernity and federal DOT regulations in North Dakota, rumor has it there may still be drivers out there who measure highway distances in six-packs.)