Thanks for the code, and for the reminder about setting the printer drivers to output to file. I did do that on each one that supports it--usually without much success except for the Generic PostSript Printer. I'm glad to learn that GS may be able to handle long filenames. It makes it worth putting in more time on the solution. I can't help but wonder though if it is really wise to take a simple one-pass, two-line process and turn it into a complicated group of objects and methods just from a sustainability standpoint. Perhaps the complexity will diminish once I figure out how it works. We normally don't save any of the interim files; the only output we need is paper or pdf file. Of course, interim files can be erased after they are converted but it's more pfaffing around, as is having to rename the file or copy it to a different directory. Free is good, but it comes with a price tag. And I can't help but wonder if this solution might not also be broken by Microsoft's updates. If so, that becomes my problem once again. At least with a purchased solution, the vendor is responsible for insuring that it continues to work in spite of Microsoft! But my clients don't have $1500 for at the moment so I guess I'll plunder onward :-)

One question about the word print command: Have you tried setting background printing (the first parameter on the print command) false? I usually do that so Word doesn't blunder onward (and perhaps quit) before the print to file is complete Maybe .waitforfile wouldn't be needed?

Do you have any idea what is required to get this working in the production environment? I don't have much cooperation from IT so it needs to be pretty much "turn key" from the client's point of view--for both the LAN and Terminal Server installs.