I thought I had printing issues pretty well figured out, but I'm stumped again. But this is my first in-depth foray into ATE land.

We were running on a WINDOWS server, connecting with CITRIX I believe, using
local printers (DEVICE=AUXLOC) and PASSTHROUGH=YES. Some report files had
embedded PCL commands, and life was good.

We have moved to a LINUX server, and initially made no changes to the LOCAL.INI file, and are now connecting with ATE 6.0. The PCL commands are no
longer being processed by the printer (an HP4050N using a PCL5e driver in my
test case), but are instead being printed as part of the text.

First I tried turning PASSTHROUGH=NO. No effect.

Then I configured an "alternate" printer with a GENERIC TEXT driver, which defaulted to RAW mode. I tried this with PASSTHROUGH=NO and =YES. No
significant effect.

Then I logged in using ZTERM and printed to the HP4050N. No problem'o. And, interestingly, PASSTHROUGH YES or NO makes no difference, ZTERM prints to the local printer just fine in either case.

I haven't read every reference to printing in the help file, but I've read a number of them. I did find the piece on "DEVICE = AUXLOC:", which refers to printer ini files on the client PC. I tinkered with a LOCAL.INI printer ini file on my WINDOWS XP machine on which ATE is running, but that didn't have any effect. It's not clear to me under what conditions a printer ini on the client (ATE) PC would be processed.

I realize GDI is the way to go in the future, but that's not going to happen within the time frame that I have to solve this issue.

Any ideas aside from moving from ATE to ZTERM?

John K.

John and I work with the same client and are experiencing the same printing problems. Here is my 2 cents. I have a local HP P2015 Laser Jet. I have connected to our client using ATE and ZTerm. Printing via AUXLOC (LOCAL) has worked flawlessly in all my tests with both emulators.

A few general comments/observations that might be helpful, or at least relevant:

1. For local (aka aux port, i.e. DEVICE=AUXLOC: ) printing, the PASSTHROUGH command (along with most others) in the server-side printer init file is (are) ignored. The PASSTHROUGH option will be set on the client side, either in a client-side printer init file, or in the Connection Properties > Printer dialog. (See points 2 and 3 below.)

2. If the server-side printer init file contains DEVICE=AUXLOC: with no printer name appended to it, then all the local printer settings will be determined by ATE's Settings > Connection Properties > Printer dialog. (This is similar to the way local printing works in ZTERM.)

3. To use a client-side printer init file, you must append its name to the DEVICE=AUXLOC: statement in the server-side printer init file. For example, if you want to use a client-side printer init file called LOCAL (e.g. LOCAL.PQI[1,7]), then your server-side printer init file (regardless of its name) should contain DEVICE=AUXLOC:LOCAL

4. To print PCL sequences, you must use PASSTHROUGH mode. Therefore, you will either need to use a client-side printer init file with PASSTHROUGH=ON, or select the "Passthrough (raw)" radio button in the Connection Properties > Printer dialog. If you try to print PCL ESCAPE sequences in GDI mode (PASSTHROUGH=OFF), they will just print as ordinary text (with some kind of graphic symbol for the ESC).

5. Some printers simply do not support PASSTHROUGH mode. These are sometimes referred to as "Windows only" because they require the Windows GDI system (i.e. accept only rasterized output). Even HP makes such printers, although mainly it is just the lower-end ink jet printers that suffer from this limitation. If you try to print in PASSTHROUGH mode to a "Windows-only" printer, typically you get nothing at all. The only workaround for this problem is to switch to GDI printing, or get another printer.

6. Some printer drivers simply do not support PASSTHROUGH=ON, even when the printer itself does. As with all other issues that might be related to the printer driver, a good first step is always to try updating the driver. (You wouldn't believe how often this solves problems after hours of time wasted trying other things.) If that doesn't work, the other workaround in this case is to use the Generic Text-Only printer driver (which does support PASSTHROUGH) instead.

Thanks for the extended tutorial. Suggestion #1 did the trick and will be easy to implement. Problem solved.