We struggled with variations of this problem for several months back in the middle of 2000. Here's the abbreviated history:
The problem first appeared when printing from a workstation on NT or W2K to a printer owned by a workstation running some other version of Windows. (There are many possible combinations here, and although we first tried to enumerate and solve each one separately, we eventually abandoned that as unproductive and found a different solution.)There was quite a bit of discussion about this on the Microsoft online support forums, with various partial workarounds proposed, but none of them really dealt with the underlying problem, which was the migration from an older way of handling PASSTHROUGH printing in Windows (dating back to WIN16 days) to a completely different set of API functions for handling printers which started appearing in WIN32. In W95 and W98, they (Microsoft and printer driver developers) apparently made an effort to maintain upward compatibility, but by the time NT and W2K were out, they had pretty much stopped worrying about the old method. For the most part it still worked, but the edges were unravelling, particularly when the print process involved communication between drivers for two different releases of the operating system.
Finally we opened up a case with Microsoft's Development Support team and after they concluded the same (that it was hopeless trying to fix the old system) we decided to rewrite the printer logic using the new WIN32 API functions.
This rewrite was first released in 4.6(756) (Nov 2000) and did indeed solve the problem with the unwanted formfeeds. It also eliminated the need to worry about RAW vs EMF and drivers that did or did not support PASSTHROUGH properly. Now it seems that PASSTHROUGH works in all cases (provided that the printer is not a GDI-only printer, in which case PASSTHROUGH will never work.)
So, unfortunately we cannot offer you any solution other than updating to 4.6. If you're on the USS program that's a cost free and nearly painless operation; otherwise you can contact us to determine the update price. I know that probably isn't what you or the customer want to hear, particularly if they view this as a bug fix, but this is really an excellent example of us being forced to continue developing A-Shell just to keep up with operating system updates that are out of our control. That's exactly what the USS program is designed to fund.
If and when you update to 4.6, there are a number of other printing-related features that you may find helpful. One is the new STRIPFF parameter which eliminates unwanted formfeeds caused by programs that insert a formfeed at the start of the printout, assuming the AMOS spooler would ignore it. Used in conjunction with AUTOFF, I think that pretty much all formfeed situations are handled.
Another Windows printing improvement in 4.6 was PITCH=AUTO, which in many cases allows you to just ignore the whole problem of using ESCAPE sequences to switch between 80/132 columns. This allows you to use regular (non-PASSTHROUGH) printing and thus will work with any printer, even the GDI-only ones. Another advantage of switching to non-PASSTHROUGH printing is that you can begin to use A-Shell's GDI printing commands for graphic support, which were significantly improved in 4.6, including support for the Windows 2000 fax system, BIN support, and image printing.
